switch to pragma-controlled Postgres style relational scoping #6495
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit changes the relational scoping rules to follow Postgres except for GROUP BY expressions which check column aliases before the input table (like Google SQL). This is favored as the default for SuperSQL because it doesn't change binding when a dynamic input transitions to a typed input (and thus a field that was present but unknown in the input changes the GROUP BY binding of a column alias). This behavior can be overridden now with "pragma pg=true" which says to follow Postgres semantics and favor the input table over any column alias in GROUP BY expressions. As a result, column aliases are no longer visible in WHERE clauses or SELECT expressions in line with Postgres semantics (and ANSI and Google SQL). We added some light documentation to the pragma section of the book in this PR, but more details and an explanation of the rationale for this design will be forthcoming in a future PR from the book-sql branch.
nwt
approved these changes
Jan 7, 2026
| * `1` for one-based indexing | ||
| * `pg` - controls the precedence of scoping for GROUP BY clauses in SQL operators | ||
| * `false` to follow Google SQL semantics of resolving identifiers first from column aliases then from the input table | ||
| * `true` to follow Postgres semantics of resolving identifiers first from the input table then from the column aliases |
Member
There was a problem hiding this comment.
Suggested change
| * `true` to follow Postgres semantics of resolving identifiers first from the input table then from the column aliases | |
| * `true` to follow PostgreSQL semantics of resolving identifiers first from the input table then from the column aliases |
compiler/semantic/schema.go
Outdated
| @@ -80,7 +80,7 @@ type ( | |||
| // so latStop limits the extent of the column lookup to avoid | |||
Member
There was a problem hiding this comment.
Suggested change
| // so latStop limits the extent of the column lookup to avoid | |
| // so lateral limits the extent of the column lookup to avoid |
Collaborator
Author
There was a problem hiding this comment.
I update this comment as it was stale.
mattnibs
reviewed
Jan 7, 2026
compiler/semantic/op.go
Outdated
|
|
||
| func (t *translator) mustEvalBool(in ast.Expr) (bool, bool) { | ||
| val, ok := t.mustEval(t.expr(in)) | ||
| if ok && !val.IsError() && super.TypeUnder(val.Type()) == super.TypeBool { |
Collaborator
There was a problem hiding this comment.
Don't need the error check
Suggested change
| if ok && !val.IsError() && super.TypeUnder(val.Type()) == super.TypeBool { | |
| if ok && super.TypeUnder(val.Type()) == super.TypeBool { |
Collaborator
Author
There was a problem hiding this comment.
Good point. I blindly copied that pattern and it should really report a type error. Also for some of the other cases. I will address.
This was referenced Jan 7, 2026
mccanne
added a commit
that referenced
this pull request
Jan 7, 2026
fix lateral column alias bug introduced in #6495 This commit fixes a bug where lateral column aliases were improperly resolved after the XXX
mccanne
added a commit
that referenced
this pull request
Jan 7, 2026
This commit fixes a bug where ORDER BY scope was improperly handled because the logic favored the input table over the column aliases but the materialized output table has priority over the input table once the SELECT body scope is left. This would typically be handled by first looking into the output table but we can't do this because we do expression matching on the sem-tree expressions and we can't mix and match input expressions with the output expressions. The fix is to look in the columns first (producing input table expressions) and matching those expressions to the grouped output table columns with the expression matcher.
mccanne
added a commit
that referenced
this pull request
Jan 7, 2026
This commit fixes a bug where ORDER BY scope was improperly handled because the logic favored the input table over the column aliases but the materialized output table has priority over the input table once the SELECT body scope is left. This would typically be handled by first looking into the output table but we can't do this because we do expression matching on the sem-tree expressions and we can't mix and match input expressions with the output expressions. The fix is to look in the columns first (producing input table expressions) and matching those expressions to the grouped output table columns with the expression matcher.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit changes the relational scoping rules to follow Postgres except for GROUP BY expressions which check column aliases before the input table (like Google SQL). This is favored as the default for SuperSQL because it doesn't change binding when a dynamic input transitions to a typed input (and thus a field that was present but unknown in the input changes the GROUP BY binding of a column alias).
This behavior can be overridden now with "pragma pg=true" which says to follow Postgres semantics and favor the input table over any column alias in GROUP BY expressions.
As a result, column aliases are no longer visible in WHERE clauses or SELECT expressions in line with Postgres semantics (and ANSI and Google SQL).
We added some light documentation to the pragma section of the book in this PR, but more details and an explanation of the rationale for this design will be forthcoming in a future PR from the book-sql branch.
Fixes #5974
Fixes #6410