SQL Alias Review: Check Which Value Your Query Actually Uses

Which value does this name select?

Revenue is 100. Cost is 70. The query calculates a value of 30, filters for values above 10—and the row disappears.

That outcome can make sense if the filter refers to a different value from the calculation you were reading. A familiar name can hide a disagreement about which column or expression the database resolves.

SQL review becomes more useful when it checks that meaning directly: which value does this identifier refer to, and which rows should survive?

Why this question matters for reusable aliases

BigQuery's 15 October 2026 release notes mark reusable column aliases as generally available and opt-in. The feature lets an expression's alias be referenced later in the same SELECT list or in that query block's WHERE clause. Availability does not mean it is enabled in every project. BigQuery release notes

Google's feature documentation describes name-resolution rules and warns that enabling the feature can affect existing workloads. A physical input column takes priority over a same-named alias in the documented resolution order. Work with reusable column aliases

The lesson for a review is to inspect the names and scope surrounding the expression. Shorter SQL can still carry a meaning that is easy for a human reader to miss.

Make the ambiguity visible with one row

Consider a synthetic input table named sales:

For this exercise, profit is an existing imported field with a different definition from revenue - cost. The values and business are invented.

Now review this query in the context of the documented BigQuery rules:

SELECT
  order_id,
  revenue - cost AS profit
FROM sales
WHERE profit > 10;

A reader might follow the alias and expect the filter to evaluate 30. The existing input column named profit provides a competing meaning: 5. Under the documented column-priority rule, that input value is used by the filter, so this row does not qualify.

This is a documentation-based illustration, not the result of a live BigQuery execution. The point is the conflict a reviewer should investigate, not a claim that every SQL engine resolves the query the same way.

Give the calculation its own name and boundary

If the intended definition is revenue minus cost, make that explicit:

WITH calculated AS (
  SELECT
    order_id,
    revenue - cost AS calculated_profit
  FROM sales
)
SELECT
  order_id,
  calculated_profit
FROM calculated
WHERE calculated_profit > 10;

Here the outer filter reads a named output of the preceding query. The original profit field is not part of that output. For row A, calculated_profit is 30 and the row qualifies.

This structure makes the intended dependency inspectable. It does not make revenue minus cost the right business definition of profit. Refunds, taxes, attribution windows and cost scope still need an agreed definition when they matter to the analysis.

Review rows as well as syntax

Expand the synthetic fixture before reviewing a refactor:

Row A distinguishes the imported field from the new calculation. Row B reverses the disagreement so that one fortunate example cannot hide it. Row C checks the strict boundary: greater than 10 excludes 10.

Add cases for missing values, joins or aggregation when the real query uses them. Choose cases that could expose a different meaning, rather than expanding a fixture with many rows that all exercise the same path.

Write the expected row identifiers before running the query. That forces the review to state what “equivalent” means.

Read a refactor as a change to an analytical claim

When someone replaces repeated expressions with aliases, compare more than the visible calculation. Inspect the input schema, query scopes, filters and downstream consumers.

Ask the author to complete a short review note:

The metric means ___. Its inputs are ___. The filter uses ___. In the distinguishing fixture, rows ___ should remain because ___. The feature configuration required for this query is ___ .

That note gives another analyst something to challenge. A query that runs successfully has passed an execution check; it still needs to support the statement the report makes.

For a feature rollout, also check configuration and existing workloads through the team's normal process. Reading release notes should lead to a bounded evaluation, with an owner and expected results.

Turn a language update into a better review question

The durable question is simple: “Which value does this name select here?” It applies to a new SQL capability, a metric refactor and a dashboard whose label stayed the same while its calculation changed.