Häufig gestellte Fragen

Ähnlich wie bei anderen Paketverwaltungssystemen enthält das Repository der DuckDB-Community-Erweiterungen von der Community beigetragenen Code. Daher gibt es keine Garantien bezüglich des Inhalts der Erweiterungen. Die DuckDB Foundation und DuckLabs prüfen den Code in Community-Erweiterungen nicht und können daher nicht garantieren, dass DuckDB-Community-Erweiterungen sicher zu verwenden sind.

Hinweise zur Absicherung Ihrer DuckDB-Installation finden Sie auf der Seite Erweiterungen absichern.

Das Laden von Community-Erweiterungen lässt sich mit der folgenden Einweg-Konfigurationsoption explizit deaktivieren:

SET allow_community_extensions = false;

Hinweise zur Absicherung Ihrer DuckDB-Installation finden Sie auf der Seite Erweiterungen absichern.

Eine DuckDB-Erweiterung als Sammlung von SQL-Makros zu schreiben, tun bereits einige Erweiterungen. Die Erweiterungen pivot_table und chsql folgen beispielsweise diesem Muster.

Derzeit ist etwas C++-Wrapper-Code erforderlich, aber das ist vermutlich der einfachste Weg, eine Community-Erweiterung zu bauen und der beste Weg, eine Sammlung von Hilfsmakros sicher zu verteilen.

Eine DuckDB-Erweiterung in Rust zu schreiben ist möglich, und mehrere Erweiterungen existieren bereits, die verschiedene Beispiele zur Orientierung bieten.

Derzeit erfordert das Schreiben einer Rust-basierten DuckDB-Erweiterung Glue-Code in C++ und zwingt Sie, über DuckDBs CMake- und C++-basiertes Erweiterungs-Template zu bauen. Wir verstehen, dass das nicht ideal ist, und wissen, dass Rust-Entwickler lieber mit reinen Rust-Codebasen arbeiten. Aus diesem (und vielen anderen) Grund(en) ist eine C Extension API in Entwicklung, die DuckDB-Erweiterungen in reinem Rust ermöglichen wird. Sobald die C Extension API ausgereift ist, wird ein reines Rust-Erweiterungs-Template bereitgestellt.

Wir arbeiten daran, Go-Unterstützung für Erweiterungen hinzuzufügen.

DuckDBs Extension Template basiert auf der DuckDB-C++-API und verwendet DuckDBs CMake-basiertes Build-System. Das DuckDB-Team unterstützt derzeit nur Erweiterungen, die mit diesem Framework geschrieben werden. CMake ist jedoch recht flexibel: Es gibt beispielsweise bereits mehrere Rust-basierte Beispiele.

Zusätzlich steht seit DuckDB v1.1 eine neue C Extension API zur Verfügung.

Derzeit müssen DuckDB-Erweiterungen einen eindeutigen Namen haben. Deshalb werden Pull Requests, die Namenskollisionen einführen, nicht akzeptiert und erfordern eine Umbenennung. Die Lösung wäre manuelles Namespacing, zum Beispiel durch Voranstellen Ihres Anbieternamens vor den Erweiterungsnamen: ⟨vendor_name⟩_⟨extension_name⟩{:.language-sql .highlight}.

Beachten Sie, dass die DuckDB Foundation bestimmte Erweiterungsnamen grundsätzlich ablehnen oder eine bestehende Community-Erweiterung zur Umbenennung verpflichten kann. Existiert beispielsweise eine Kern-Erweiterung gleichen Namens oder wird eine solche erstellt, muss die Community-Erweiterung gleichen Namens umbenannt werden, um Verwechslungen zu vermeiden („Lade ich die Community-Erweiterung oder die Kern-Erweiterung?“). Der vielschichtige Charakter von Erweiterungsnamen erfordert, dass wir auch historische Erweiterungsnamen, Marken usw. berücksichtigen. Die DuckDB Foundation behält sich daher das Recht vor, über Erweiterungsnamen im Einzelfall zu entscheiden.

Die Toolchain zum Kompilieren von DuckDB-Erweiterungen enthält möglicherweise nicht alle Build-Zeit-Abhängigkeiten, die zum Bauen Ihrer Erweiterung erforderlich sind. Ist das der Fall, öffnen Sie bitte einfach einen Pull Request, der Toolchain-Komponenten als optionale Extras hinzufügt.

Alternativ können Sie versuchen, die Installation der benötigten Abhängigkeiten über das Makefile in Ihrem Erweiterungs-Repository hinzuzufügen. Sie sollten jedoch bedenken, dass das zu einem anfälligeren Build-System führen kann, mit entsprechend höherem Wartungsaufwand, wenn DuckDB und seine Toolchain aktualisiert werden.