fix(plan): support GROUPING expressions in ROLLUP ORDER BY

[ck89119]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #25287

What this PR does / why we need it:

ROLLUP, CUBE, and GROUPING SETS are expanded into an internal UNION ALL plan. The original ORDER BY is bound above that union, where source columns referenced by expressions such as GROUPING(region) are no longer visible even when the same expression is already projected.

This change rewrites an ORDER BY expression that exactly matches a select-list expression to its projection ordinal before building the internal grouping-set union. It reuses the projected value, preserves the final output schema, and does not relax the rules for explicit user-written set operations.

The change also adds planner unit coverage and a distributed ROLLUP regression case with real NULL values.

Validation:

• go test -count=1 ./pkg/sql/plan
• go build ./pkg/sql/plan/...
• go vet ./pkg/sql/plan/...
• modified helper coverage: 100%
• make
• rollup BVT: 112 passed, 0 failed, 2 ignored
• git diff --check

make static-check remains blocked by existing pkg/common/docfilter CGo unsafe molint violations; the same failure was reproduced on a clean main checkout.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[aunjgr]

Rewrite by AST text is fragile — GROUPING(a) vs GROUPING(t.a) will always mismatch. Should resolve to canonicalized columns after name binding, not before.

[XuPeng-SH]

Requesting changes on the latest head. The earlier qualified/nested GROUPING() issues look much better, but the new hidden-order-key approach currently bypasses the existing SELECT DISTINCT ORDER BY rule and can change visible DISTINCT results.

Repro on this head:

select distinct grouping(a)
from select_test.bind_select
group by a with rollup
order by grouping(a) + a;

For comparison, the ordinary path correctly rejects the same shape:

select distinct a
from select_test.bind_select
order by a + 1;
-- for SELECT DISTINCT, ORDER BY expressions must appear in select list

The reason is that prepareGroupingSetOrderByProjects appends every ORDER BY expression containing GROUPING() as a hidden branch projection and rewrites the UNION ORDER BY to an ordinal (query_builder.go:3843-3883). Those hidden projections are then included in each generated branch while preserving Distinct: selectClause.Distinct (query_builder.go:3101-3103). By the time buildUnionWithResultLen binds ORDER BY, it sees only an ordinal, so the normal distinct guard in OrderBinder (order_binder.go:140-143) is never reached.

This is not only an error-policy mismatch: if the query is allowed, the hidden key participates in branch-level DISTINCT and is then trimmed from the final output, so different hidden keys can become duplicate visible rows after trimming.

Suggested fix: preserve the existing DISTINCT contract before injecting hidden grouping-set order keys. For SELECT DISTINCT, only rewrite to a hidden key when the ORDER BY expression is already a visible select-list expression (or rewrite to that visible ordinal); otherwise return the same error as the ordinary ORDER BY path. Please add regression coverage for the repro above and the allowed case where the full ORDER BY expression is selected.