maint: prepare duckdb 2.0 compatibility

[smithclay]

Summary

• track DuckDB 2.0 ("cyanoptera") for 2.0 compatibility work, now at the branch tip fc9d6e9 (rebased on main @ c3dff30)
• update extension code for changed DuckDB C++ APIs: identifiers, vectors, table outputs, fallible scalar functions, and (new on the tip) FunctionSignature-based table-function parameters and the reshaped QueryResult
• fix static extension linking, which changed on the tip and left the daemon without parquet/json without any build error
• update Quack docs to use DuckDB 2.0 CONNECT for ordinary server-side SQL, keeping quack_query as a one-shot fallback

DuckDB 2.0 tracking

There is still no v2.0.0 tag (latest release is v1.5.6), so the v2.0-cyanoptera branch tip is the newest 2.0 ref:

• duckdb submodule → fc9d6e9 (tip of v2.0-cyanoptera, 2026-10-02), up from 3a604ab (1233 commits)
• extension-ci-tools → 969bc76. ci-tools now has its own v2.0-cyanoptera branch, so the submodule, .gitmodules, and the reusable-workflow @ref/ci_tools_version follow it instead of main, which will move on to 2.1
• duckdb_version in MainDistributionPipeline.yml stays v2.0-cyanoptera

duckdb_version is both the git ref and the version stamped into artifacts. A branch name is not a semver, so the stamped version has no published extensions to resolve. Pin to the tag once 2.0.0 lands.

What changed on the tip (3a604ab → fc9d6e9)

APIs

• TableFunction::named_parameters / arguments are gone; parameters are a Python-style FunctionSignature. otlp_serve/otap_serve now declare their options as a typed **kwargs schema (WithTypedKwargs, the same mechanism read_csv uses). An omitted option is not passed, so bind defaults behave exactly as before. Side effect: duckdb_functions() now lists those options by their real names instead of colN.
• QueryResult lost GetValue() and QueryResultType. query --format box renders through QueryResult::ToBox, which keeps main's BoxRenderer output rather than ToString()'s debug form, and the seal harness reads its count through Fetch().

Linking (silent breakage)

• A statically linked extension now registers itself only if the program roots it via link_extension_libraries. That function reads the link set DuckDB resolves after its extension loop, and our CMakeLists.txt runs inside that loop, so the daemon and both harnesses linked no parquet/json/core_functions at all. Everything compiled, then duckdb-otlp convert --to x.parquet failed with Copy Function "parquet" is not in the catalog. otlp_link_duckdb_extensions defers the call to the end of configure.
• Loading an extension config no longer implies linking it into the shell/unittest. extension_config.cmake now calls duckdb_extension_statically_link(otlp); without it, build/release/duckdb had no otlp_serve.

Validation

On fc9d6e9 (macOS arm64):

• GEN=ninja make release: clean
• make test: 23/23 files, 387 assertions
• otlp_seal_harness: 11 cases, 204 assertions
• otlp_arrow_harness: 2 cases, 6 assertions
• pytest test/server: 247/247 (see below)
• Daemon by hand (--mode parquet): OTLP/HTTP protobuf, NDJSON, and gzip ingest → 202; shutdown seals; query reads back through the Parquet views; export writes NDJSON
• DuckLake seal end to end: no ducklake is published for this build, and the v2.0.0-alpha39998 binary null-derefs on load (ABI mismatch: it was built from eb7b95df82). So I built ducklake from source at the commit DuckDB's 2.0 branch pins (e8924cf) and ran otlp_serve(catalog := 'lake'): POST logs/traces/metrics → otlp_flush sealed all rows in one snapshot, 0 seal failures, otlp_stop dropped 0
• The clang-format 11.0.1 pre-commit hook could not run locally (x86-only wheel, no Rosetta), so the code-quality job is the formatting check for this push

daemon-compile: fixed by building ducklake into the daemon

This used to be a known failure. The default local-ducklake mode ran INSTALL ducklake at startup, and no ducklake is published for a 2.0 dev build. The v2.0.0-alpha39998 binary null-derefs against the tip. No version string fixes this, because the real problem is that the daemon only works when a published extension happens to match its ABI.

Now ducklake is linked into the daemon instead (a4d5b615):

• DUCKDB_OTLP_BUILT_IN_EXTENSIONS links extensions taken from DuckDB's own pinned configs (duckdb/.github/config/extensions/<name>.cmake: the commit and patches DuckDB builds against this source), so the ABI matches by construction.
• make server-release (Docker and both daemon CI jobs) sets it to ducklake and first builds CRoaring, ducklake's only dependency, into build/deps. The extension distribution builds are unchanged.
• Core(name) reports BUILT_IN when LinkedExtensionRegistry says the binary links it, so no INSTALL/LOAD is emitted. Because this asks the binary itself rather than a build flag, the two cannot drift.
• The image stops priming ducklake.
• The DuckLake read-back in test_init_sql_adds_a_parquet_destination_next_to_the_ducklake_catalog now goes through the binary under test. The host's duckdb==1.5.6 cannot open a 2.0-format database (storage version 69).

Verified:

• The local-ducklake daemon with an empty extension cache ingests, seals and reads back, with zero downloads.
• pytest test/server passes 247/247 on macOS and against the Docker-built linux/arm64 daemon-export binary.

Still open

• quack is not built in. On 2.0 it draws its tokens from the writable crypto module that only httpfs (OpenSSL) provides. Building it in means building httpfs in, which goes against the image's no-libssl design. Until 2.0.0 ships, Quack, docker-smoke, and the cloud modes (httpfs/aws/iceberg/postgres/gcs) still need published extensions, and the Dockerfile still pins DUCKDB_VERSION to v1.5.6 for them.
• The same gap is why pages.yml, the host duckdb CLI downloads, duckdb==1.5.6 in the server tests, and the Makefile's WASM VERSION_FIELD all stay on the 1.5 line.

Notes

• src/otlp_column_promote.cpp includes duckdb/main/query_result.hpp; 2.0 removed materialized_query_result.hpp.
• otlp_server_list emits one row per listener using SetChildCardinality.
• windows_amd64 builds against DuckDB 2.0 here for the first time, so watch it on the next run. The deferred cmake_language(DEFER) call only applies inside the non-Windows daemon/harness block.
• AGENTS.md documents both 2.0 changes: function metadata now comes from the function's own FunctionSignature (AddPositionalOnly is how to name a reader's argument), and embedding executables must link DuckDB's extensions through otlp_link_duckdb_extensions.