v0.18.0

Breaking

Function resolution is now keyed by (schema, name), not name alone.

A worker may register the same function name in more than one catalog schema. Previously the worker kept a flat name -> classes registry, so two such functions collided as overloads and any call raised Ambiguous function call — registration was schema-aware, but dispatch was not.

BindRequest gains schema_name, and the worker builds a second index keyed by (lowercased schema, function name). A schema-qualified lookup is exact, so example.main.f(x) and example.data.f(x) reach different implementations. Callers that send no schema search every schema and get a cross-schema ambiguity error naming the schemas involved. Functions declared via the legacy functions list register into the catalog's default_schema.

Client now requires schema_name. It is a required keyword on table_function, table_in_out_function, scalar_function, table_buffering_function, and table_scan_resumable, so a Client-driven bind is never ambiguous. vgi-client gains --schema (defaults to main).

Protocol version 1.0.0 → 1.1.0. Requires a VGI DuckDB extension built against 1.1.0; older clients are rejected at dispatch with a directional ProtocolVersionError.

Other changes

• MetaWorker routes bind/init on attach_opaque_data, which is what identifies the catalog. Its no-attach fallback now prefers a sub-worker declaring the name in the requested schema rather than matching the bare name — previously a second catalog declaring the same main.<fn> was unreachable.
• The wire field stays nullable for COPY handler binds, which are advertised at catalog level and carry no schema.
• Removed the cache_interleaved fixture. It declared supports_batch_index and then emitted descending batch_index on a single stream — a protocol violation that only survived because the DuckDB extension's standalone vgi_table_function() path never wired that flag, so the monotonicity check never ran. That path has been removed from the extension.
• New fixtures covering both collision shapes: one name across two schemas of a catalog, and one schema and name across two catalogs served by a single worker process.