Shipped libduckdb.a links none of the extensions its build config declares

[datlechin]

Problem

The published Libs/libduckdb.a linked none of the extensions scripts/duckdb-macos-extensions.cmake declares. That file lists core_functions, json, parquet, icu and autocomplete, and exists specifically to stop DuckDB downloading them from extensions.duckdb.org on first use. The binary was never rebuilt from it.

Probed against the shipped libduckdb.a (v1.5.2):

core_functions sum   FAIL   Catalog Error: ... exists in the core_functions extension
core_functions round FAIL
json cast            FAIL
json extension       FAIL
parquet              FAIL   Catalog Error: Copy Function with name "parquet" is not in the catalog
icu/strftime         OK

So on a Mac that cannot reach extensions.duckdb.org, sum, avg, round, median, date_trunc, json_extract and the rest fail with "not in the catalog, but it exists in the <name> extension". That is the exact failure the cmake file was written to prevent, and the comment at the top of scripts/check-duckdb-offline-metadata.sh still describes the library as "the bare amalgamation", which is what it in fact was.

The metadata queries in DuckDBSchemaQueries.swift work around it by avoiding current_database(), current_schema(), key_column_usage and referential_constraints, so browsing worked. Anything a user types that reaches an aggregate did not.

Proposed solution

Fixed in #2621, which rebuilds and republishes the library. After the rebuild:

autocomplete     linked
core_functions   linked
icu              linked
json             linked
parquet          linked

The lasting part is scripts/check-duckdb-extensions.sh, added in the same PR. It parses duckdb_extension_load out of the cmake config and probes the shipped binary for each one, so the config and the artifact cannot drift apart again unnoticed. Run it after bumping DUCKDB_VERSION, after editing the extension config, and before publishing a rebuilt library.

This issue records the defect itself, because the shipped library was wrong for however long it has been published and that is worth a note independent of the PR that happened to find it.

Alternatives considered

Leaving the workaround in DuckDBSchemaQueries.swift and documenting the limitation. That only covers the queries TablePro issues; a user's own SQL still fails, and the workaround has to be remembered by everyone who touches those queries.

Related database type

DuckDB