Repository navigation
Read a column over an earlier alias of its name - #10
Merged
Merged
Conversation
A name in a select list that an earlier item gives as an alias was always
read as that alias, even where a source of the FROM has a column of that
name.
SELECT a AS b, b AS c FROM p -- p has b
c came out reading p.a. Snowflake and DuckDB give c the value of p.b:
the column wins over the alias, in the select list as in GROUP BY. And
BigQuery reads no alias of its own select list at all.
An identifier a source in scope is known to have now stays a column
reference, alone or inside an expression. Where no source is known to
have it, the alias is the only name in sight and is read through as
before.
Claude-Session: https://claude.ai/code/session_0144SufcRMDVctcvHmcb1665
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Patch 11 of the engine fork that collin pins (dbt-collin decision 0028). An identifier in a select list that a source of the
FROMis known to have is now read as that column, even when an earlier item gives an alias of that name.Until now the earlier alias always won:
SELECT a AS b, b AS c FROM p, wherephasb, came out withcreadingp.a.Snowflake and DuckDB give
cthe value ofp.b. On Snowflake,select a as b, b as c from (select 1 as a, 2 as b)returnsc = 2. The column wins over the alias, in the select list as inGROUP BY. BigQuery reads no alias of its own select list at all.The change
resolve_lateral_alias_sourcesnow leaves an identifier as a column reference whencandidate_tables_for_columnfinds a source in scope with that column, through CTE and derived-table columns or the schema handed in.candidate_tables_for_columnbecomespub(super)so the select analyzer can ask.Tests
a_column_wins_over_an_earlier_alias_of_its_name, on Snowflake and DuckDB:creadsp.a.cargo fmt --all --checkis clean.Measured through collin
--indirecttoo, dump identicalcountry as country_namebesidecountry_code as countrynow readscountryCOALESCEor aCASEand read again in a hash, a window key or a later expressioncatalogue_entriesgives its hand-written lineage: both marks of IL-William/dbt-collin#29 goNothing goes to pondpilot/flowscope.
🤖 Generated with Claude Code
https://claude.ai/code/session_0144SufcRMDVctcvHmcb1665