You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
duckdb: a table name or alias used as a value (SELECT p FROM plan p, plan_doc(p)) is an unknown column #4677
main at commit 3ad8b20, built with CGO_ENABLED=0 go install github.com/sqlc-dev/sqlc/cmd/sqlc@3ad8b20fb02b5bea81591b673da0758b8685d951. sqlc version prints v1.31.1.
What happened?
DuckDB lets a query refer to a table or its alias as a value. The reference is a STRUCT of the row's columns, which is the usual way to hand a whole row to a macro:
CREATE MACRO plan_doc(r) AS json_object('id', r.id, 'boxSize', r.box_size, 'price', r.price);
SELECTp.id, plan_doc(p) AS doc FROM plan p;
The sqlc DuckDB engine rejects every form of that reference with unknown column:
query
sqlc
DuckDB v2.0.0 (DESCRIBE)
SELECT p FROM plan p
unknown column "p"
STRUCT(id UUID, box_size VARCHAR, price DOUBLE)
SELECT plan FROM plan
unknown column "plan"
same struct
SELECT CAST(p AS VARCHAR) FROM plan p
unknown column "p"
VARCHAR
SELECT plan_doc(p) FROM plan p
unknown column "p"
JSON
SELECT plan_doc(p.id) FROM plan p
generates
JSON
The last row shows the macro itself is fine. It is the bare row reference that does not resolve.
A view in the schema that uses the form fails the same way: with CREATE VIEW plan_document AS SELECT id, plan_doc(p) AS doc FROM plan p in schema.sql, every sqlc generate ends in schema.sql:1:1: view "plan_document": unknown column "p".
Expected: a one-part name that matches a relation in scope and no column resolves to a struct of that relation's columns, like DuckDB itself.
CREATETABLEplan (
id UUID NOT NULL,
box_size VARCHARNOT NULL,
price DOUBLE
);
CREATE MACRO plan_doc(r) AS json_object('id', r.id, 'boxSize', r.box_size, 'price', r.price);
SQL queries
-- name: RowStruct :manySELECT p FROM plan p;
-- name: RowText :manySELECTp.id, CAST(p ASVARCHAR) AS row_text FROM plan p;
-- name: RowMacro :manySELECTp.id, CAST(plan_doc(p) ASVARCHAR) AS doc FROM plan p;
Hi, I'd like to take this issue. I've reproduced it locally on current main: both SELECT p FROM plan p and plan_doc(p) fail with unknown column "p". My plan is to fix the analyzer so a single-part identifier that matches a relation in scope resolves to a struct of that relation's columns, instead of reporting an unknown column. Does that sound right? One more thing: open PR #4661 touches the same area (typeColumnRef in internal/core/analyzer/expr.go) for multi-part references — should I coordinate with it, or treat this as a separate fix?
Activity
Tidehyc commentedon Nov 7, 2026
Hi, I'd like to take this issue. I've reproduced it locally on current main: both
SELECT p FROM plan pandplan_doc(p)fail withunknown column "p". My plan is to fix the analyzer so a single-part identifier that matches a relation in scope resolves to a struct of that relation's columns, instead of reporting an unknown column. Does that sound right? One more thing: open PR #4661 touches the same area (typeColumnRefininternal/core/analyzer/expr.go) for multi-part references — should I coordinate with it, or treat this as a separate fix?