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
compiler: expand stars in the query text on the core path (#4567)
* compiler: expand stars in the query text on the core path
The core analyzer already resolved a star to the columns it covers, but
only for the result set — the query it handed to codegen still said
"SELECT *", so the generated SQL asked the database for whatever the
table happened to hold at run time rather than the columns sqlc scanned
into. Every case in the corpus that selects a star generated different
code through the core than through the legacy path.
The analyzer now reports each star along with the columns it stands for,
sharing one list with the analyzers of the queries nested in it so a
statement reports the stars in its subqueries and CTEs too. The compiler
turns those into edits on the query text, which is where the engine's
quoting rules and SQLite's jsonb wrapping live and where the legacy path
already does the same rewrite — the two now produce byte-identical SQL
across the corpus.
Rewriting means reparsing to check the edit produced valid SQL, and the
core path analyzes statements concurrently. A parser holds too much
state for two goroutines to share one, so the compiler keeps the
constructor and a goroutine builds its own.
181 of the 527 cases failing under the core context now pass.
* compiler: fix what the star dedupe claims, and prove it is needed
Review of the previous commit turned up three things.
The dedupe in expandCore was justified by a CTE analyzed twice, which
does not happen — a CTE is analyzed once and cached. Instrumenting it to
panic on a duplicate showed the corpus never hits it at all. The real
source is an expression typed a second time when a later clause refers to
the output name it was given: "SELECT (SELECT * FROM baz LIMIT 1) AS x
FROM foo GROUP BY x" reports the star in the subquery once for GROUP BY
and once for the target list, and dropping the dedupe turns that query
into an overlapping edit. The comment now says so and the query is part
of the star_expansion_core case on every engine, where it generates what
the legacy path generates.
expandCore returned an error it never produced, so it returns only edits.
newParser was set on the core path alone, leaving a nil func field on a
Compiler built the other way. Nothing calls it there today, but a field
that is only sometimes valid is one to get wrong later, so the legacy
path sets it too and takes its own parser from it.
* compiler: set newParser for the engines main added, and cover hidden columns
Rebasing onto main brought two things this change has to answer for.
SQL Server and DuckDB were added to initCore assigning c.parser
directly, while this branch had taken to deriving c.parser from
c.newParser at the end of the same switch. Neither side conflicted, so
the rebase produced a switch that leaves newParser nil for those two
engines and then calls it — every SQL Server and DuckDB query set
panicked. They set newParser like the rest now.
An fts5 table offers columns it does not declare, and a star must not
expand to them. The analyzer already skips a hidden column, and the
merge carried that into the star's column list along with the result
set, which is what it should do. Nothing covered it: the fts5 case
selects named columns, and it only runs under the opt-in core context.
star_expansion_core selects a star from an fts5 table on sqlite, where
it runs in the default suite, and expands to the declared column alone
the way the legacy path does.
The goldens are regenerated for codegen emitting any over interface{}.
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments