When a dimension SQL references a struct field like `stage.stage_id`, the
aliaser previously skipped it because `column_names.length !== 1`. After
joining tables that have a column with the same name as the struct root
(e.g. `devusers.stage` alongside `issue.stage`), DuckDB's binder raises
an ambiguous column reference error before the query can run.
Make the aliaser schema-aware: introspect each table's physical columns via
`DESCRIBE` in the browser and node wrappers, then rewrite a multi-part
column ref as `<tableName>.<root>.<rest...>` only when the leading
identifier is a known column on the current table. Cross-table references
(`customers.id`), already-qualified refs, lambda-bound identifiers, and
unknown multi-part refs are left untouched.
Falls back to the legacy length-1 behavior when schema information is not
supplied, preserving backwards compatibility.
Summary
When a dimension SQL references a struct field like
stage.stage_id, the aliaser previously skipped it becausecolumn_names.length !== 1. After joining tables that expose a column with the same name as the struct root (e.g.devusers.stagealongsideissue.stage), DuckDB's binder fails with:The query can't even run because the bare `stage` resolves to two different columns in scope.
What changed
Make the aliaser schema-aware:
Decision matrix
Files touched
Test plan