Environment:
- DuckDB 1.5.4 (Variegata), client and server (same version, verified)
- quack core extension (autoloaded), platform osx-arm64 + linux-amd64 (in-cluster), both reproduce
- Server has two secondary catalogs ATTACHed via REST: iceberg extension (Iceberg REST) and lance extension (Lance REST
namespace), both through Apache Gravitino
Summary:
When the Quack server has ATTACHed external catalogs (here: an Iceberg REST catalog and a Lance REST catalog), a client that
connects via ATTACH 'quack:host' AS remote cannot query tables that live in those server-side catalogs. The documented happy
path a table in the server's default catalog (FROM remote.hello) works. But remote.<attached_catalog>..
fails with a type-resolution error (Type UNKNOWN / a QuackScan failure).
The functional form quack_query('quack:host', '<sql>', token => ...) runs the same query against the same tables with no
problem, because the SQL executes entirely server-side and only the result set is serialized.
Repro:
Server:
INSTALL quack; LOAD quack;
INSTALL iceberg; LOAD iceberg;
-- secrets for object storage omitted
-- secondary catalog ATTACHed on the SERVER (Iceberg REST):
ATTACH 'iceberg_lakehouse' AS ice (TYPE ICEBERG, ENDPOINT 'http://<rest>/iceberg', AUTHORIZATION_TYPE 'none');
CALL quack_serve('quack:localhost', token => 'super_secret');
Client (separate DuckDB instance):
INSTALL quack; LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'super_secret');
ATTACH 'quack:localhost' AS remote;
-- (a) a plain table in the server's default catalog — WORKS
FROM remote.some_local_table;
-- (b) a table in the server's ATTACHed Iceberg catalog — FAILS
SELECT * FROM remote.ice.demo.smoke;
-- <paste the exact error from your terminal here — Type UNKNOWN / QuackScan>
Workaround that works (same server, same table):
SELECT * FROM quack_query('quack:localhost', 'SELECT * FROM ice.demo.smoke', token => 'super_secret'); -- returns rows
Expected:
remote.ice.demo.smoke resolves and returns the same rows as the quack_query() form — i.e. ATTACH ... AS remote should expose
the server's secondary attached catalogs (or at minimum surface a clear error that nested/attached catalogs aren't
replicated), not fail on type resolution.
Actual:
Querying any table in a server-side ATTACHed catalog over remote.* fails with a type-resolution error (Type UNKNOWN) /
QuackScan failure. Only tables in the server's default catalog are reachable via ATTACH.
Hypothesis / questions for maintainers:
- Does ATTACH 'quack:...' only replicate the server's default catalog, by design? If so, can it enumerate/expose secondary ATTACHed catalogs (Iceberg/Lance) too?
- The failure looks like client-side column-type resolution over the wire for extension-backed tables (Iceberg/Lance types). Is there a type that doesn't round-trip through the catalog-replication path?
- Is quack_query() (server-side execution) the intended pattern for federating over attached catalogs, with ATTACH reserved for single-catalog mirroring? A docs note either way would help.
Environment:
namespace), both through Apache Gravitino
Summary:
When the Quack server has ATTACHed external catalogs (here: an Iceberg REST catalog and a Lance REST catalog), a client that
connects via ATTACH 'quack:host' AS remote cannot query tables that live in those server-side catalogs. The documented happy
path a table in the server's default catalog (FROM remote.hello) works. But remote.<attached_catalog>..
fails with a type-resolution error (Type UNKNOWN / a QuackScan failure).
The functional form
quack_query('quack:host', '<sql>', token => ...)runs the same query against the same tables with noproblem, because the SQL executes entirely server-side and only the result set is serialized.
Repro:
SELECT * FROM quack_query('quack:localhost', 'SELECT * FROM ice.demo.smoke', token => 'super_secret'); -- returns rowsExpected:
remote.ice.demo.smoke resolves and returns the same rows as the quack_query() form — i.e. ATTACH ... AS remote should expose
the server's secondary attached catalogs (or at minimum surface a clear error that nested/attached catalogs aren't
replicated), not fail on type resolution.
Actual:
Querying any table in a server-side ATTACHed catalog over remote.* fails with a type-resolution error (Type UNKNOWN) /
QuackScan failure. Only tables in the server's default catalog are reachable via ATTACH.
Hypothesis / questions for maintainers: