Stuart Henderson <s...@spacehopper.org> writes:
> On 2024/06/01 17:02, Sebastien Marie wrote:
>> Hi,
>>
>> I would like to import duckdb (https://duckdb.org/) port.
>>
>> DuckDB is a high-performance analytical database system. It is designed to
>> be
>> fast, reliable, portable, and easy to use. DuckDB provides a rich SQL
>> dialect,
>> with support far beyond basic SQL. DuckDB supports arbitrary and nested
>> correlated subqueries, window functions, collations, complex types (arrays,
>> structs), and more.
>>
>> The port installs the CLI with several extensions and the shared lib,
>> but no bindings for external language.
>>
>> Comments or OK ?
>> --
>> Sebastien Marie
>>
>
> It would be nice to have duckdb in the tree. I think it's not quite as
> fast as clickhouse-local but seems more straightforward. A few comments:
>
> - No need to set DISTNAME, that is the default.
no problem, done locally
> - Personally I would use GH_* rather than DIST_TUPLE, there's not really
> an advantage to DIST_TUPLE here, and it has the downside that it doesn't
> work with portroach.
no problem, done locally
> - I'm a bit unsure about packaging the extensions as .a files, do they
> do anything useful? I would have expected to see the shared objects
> (see WRKBUILD/extension/*/*.duckdb_extension after build) instead.
I didn't looked at this aspect. It is the default installed files.
The duckdb exectuable seems to have the extensions embedded:
$ duckdb
D SELECT extension_name, loaded, installed, install_mode
FROM duckdb_extensions();
┌──────────────────┬─────────┬───────────┬───────────────────┐
│ extension_name │ loaded │ installed │ install_mode │
│ varchar │ boolean │ boolean │ varchar │
├──────────────────┼─────────┼───────────┼───────────────────┤
│ arrow │ false │ false │ │
│ autocomplete │ true │ true │ STATICALLY_LINKED │
│ aws │ false │ false │ │
│ azure │ false │ false │ │
│ excel │ false │ false │ │
│ fts │ true │ true │ STATICALLY_LINKED │
│ httpfs │ true │ true │ STATICALLY_LINKED │
│ iceberg │ false │ false │ │
│ icu │ true │ true │ STATICALLY_LINKED │
│ inet │ true │ true │ STATICALLY_LINKED │
│ jemalloc │ false │ false │ │
│ json │ true │ true │ STATICALLY_LINKED │
│ motherduck │ false │ false │ │
│ mysql_scanner │ false │ false │ │
│ parquet │ true │ true │ STATICALLY_LINKED │
│ postgres_scanner │ false │ false │ │
│ shell │ true │ true │ STATICALLY_LINKED │
│ spatial │ false │ false │ │
│ sqlite_scanner │ false │ false │ │
│ substrait │ false │ false │ │
│ tpcds │ false │ false │ │
│ tpch │ false │ false │ │
├──────────────────┴─────────┴───────────┴───────────────────┤
│ 22 rows 4 columns │
└────────────────────────────────────────────────────────────┘
>From a manual inspection of symbols in libduckdb.so, the extensions
seems to be also present in the library and after I made a simple
program using the library, I have the same output for the query: so the
extensions are inside the libduckdb.so library too.
For the usage of extensions as statically files, it seems be necessary
if you are statically compile duckdb in an application: the fact the
extensions where defined statically linked at port-compile-time seems to
force them to be also used in the same way if you compile a program with
duckdb library (I tried to link my test program statically, but failed
to find the right files to included).
So, from the previous, I think that the extensions files
(*.duckdb_extension) are only needed if you are compiling a "little"
libduckdb.so and you want to extend the capabilities at runtime.
Please note that from documentation reading, it seems there is no
default system path (only user path) where extensions are searched
automatically. So user might need to load them with full path.
What would be the preferred direction ?
1. keep things "as it"
2. do not install statical files at this point
3. split the port in several parts (maybe FLAVOR or separated ports):
- main part : duckdb executable + library without extensions (or
only minimal set)
- extension part : build the extensions and install *.duckdb_extension
files in a system directory
Thanks.
--
Sebastien Marie
