[CALCITE-7744] ORDER BY agg(col) on a query where an alias shadows col produces an invalid plan containing an aggregate call in a Project

[1fanwang]

Jira Link

CALCITE-7744

Changes Proposed

SELECT max(sal) AS sal, deptno, job FROM emp GROUP BY deptno, job ORDER BY max(sal) passes validation but fails during execution with Unable to implement EnumerableCalc.

The ORDER BY alias expansion turns the expression into max(max(sal)) after the original expression has already been validated. The inner aggregate then leaks into a Project. Validate expanded non-measure ORDER BY expressions before SQL-to-rel conversion. The query now returns Calcite's existing Aggregate expressions cannot be nested validation error instead of building an illegal plan. Measure aliases retain their existing scope and conversion path.

Verification

JAVA_HOME=$(/usr/libexec/java_home -v 21) ./gradlew :core:test \
  --tests org.apache.calcite.test.SqlValidatorTest \
  --tests org.apache.calcite.test.JdbcTest --no-daemon

The JDBC regression uses CalciteAssert.Config.SCOTT and the query above. The same test ran against production source from upstream/main and from this branch.

Raw logs

Before:
java.sql.SQLException: Unable to implement EnumerableCalc(...)
  EnumerableAggregate(group=[{0, 1}], SAL=[MAX($2)], agg#1=[MAX($3)])
    EnumerableCalc(... expr#8=[MAX($t5)] ...)
Suppressed: java.lang.RuntimeException: cannot translate call MAX($t5)
1 test completed, 1 failed

After:
SqlValidatorTest: 593 completed, 0 failed, 7 skipped
JdbcTest: 409 completed, 0 failed, 17 skipped
Gradle Test Run :core:test: 1002 completed, 0 failed, 24 skipped
BUILD SUCCESSFUL

[iwanttobepowerful]

SELECT max(sal) AS sal, deptno, job FROM emp GROUP BY deptno, job ORDER BY max(sal);

postgresql can return result, instead of throw error

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[1fanwang]

SELECT max(sal) AS sal, deptno, job FROM emp GROUP BY deptno, job ORDER BY max(sal);

postgresql can return result, instead of throw error

Thanks for raising this @iwanttobepowerful

PostgreSQL and Calcite resolve this query differently.

PostgreSQL only recognizes an output alias when it appears by itself in ORDER BY. In ORDER BY max(sal), sal therefore refers to the input column, so the query succeeds.

Calcite allows SELECT aliases inside ORDER BY expressions. Since the query defines max(sal) AS sal, Calcite expands the expression to max(max(sal)), which is invalid.

Right now this PR proposes to keep Calcite's current resolution rules. It replaces the later planner failure with a clear validation error.

I think matching PostgreSQL would require a separate conformance change that's beyond the scope of this ticket/PR