BigQuery’s new reusable aliases simplify generated SQL—but the opt-in can change what old queries mean

BigQuery has made reusable column aliases generally available, allowing an expression named in a SELECT list to be referenced later in that same list or from the query block’s WHERE clause. Google says the syntax is intended to reduce repeated expressions and unnecessary subqueries, and to make migration from warehouses including Snowflake and Teradata easier. For text-to-SQL systems, that means a generator can produce shorter, more linear SQL—but only after an administrator explicitly enables the behavior. BigQuery release notes Reusable-alias documentation

GA does not mean enabled

Reusable aliases are off by default. An administrator must set reusable_column_aliases_mode to on at the organization or project level, scoped by region. Changing the setting requires the BigQuery Admin role or the corresponding project- or organization-update permission. Teams can inspect project, organization and effective project options through BigQuery’s INFORMATION_SCHEMA views. Reusable-alias documentation

That creates a deployment contract for generated SQL: a query valid in one project may fail with “Column not found” in another where the option remains disabled. A text-to-SQL service therefore should not infer support merely from the BigQuery dialect name; it should detect the effective option or continue emitting portable subqueries and repeated expressions. This is an operational inference from Google’s documented default and configuration scope. Reusable-alias documentation

The sharper edge is semantic drift

When the feature is enabled, BigQuery resolves a physical table column before an alias, then checks the alias before an outer-query column, function argument or script variable. Google explicitly labels the resulting behavior a semantic-drift risk. Its examples show a correlated subquery switching from an outer column to a constant alias, a temporary function changing its result from 110 to 15, and a script calculation switching from a constant to a row-varying expression. Those queries can remain syntactically valid while producing different results. Reusable-alias documentation

For agent-generated SQL, validation therefore cannot stop at successful parsing or execution. Before enabling the mode, teams should regression-test stored queries, UDFs, scripts and generated-query golden sets for name collisions. Generators should assign unique aliases rather than recycle schema columns, parameters or variables. That follows Google’s own recommendation to evaluate existing workloads and avoid conflicting names. Reusable-alias documentation

The syntax still has boundaries

Aliases can only be referenced after they are defined, because evaluation proceeds left to right. They cannot be reused in several aggregation and window-function combinations, and the feature does not support BigQuery pipe syntax or Graph Query Language. Those limits matter for NL2SQL systems that mix conventional GoogleSQL with newer syntactic forms: alias reuse is a capability to negotiate, not a blanket simplification pass. Reusable-alias documentation

The practical rollout is conservative: enable the option in a test project, run result-level regressions—not just syntax checks—and expose the effective setting to the SQL generator. The feature can make machine-written queries cleaner, but its safest use begins with treating dialect configuration as part of the model’s execution context.