fix(optimizer): incorrect merge with literal alias collision

[fivetran-kwoodbeck]

Merging a derived table that projects a numeric literal (6 AS a) whose alias matches a FROM column, and is used in the outer GROUP BY, rewrites it to a bare GROUP BY a that rebinds to the column instead of the constant. This changes the query result. The fix is that _mergeable now blocks those merges.

Sample query:

SELECT s.a, SUM(s.b) AS b FROM (SELECT 6 AS a, b FROM x) AS s GROUP BY s.a;

Before, this query will return different results:

SELECT 6 AS a, SUM(x.b) AS b FROM x AS x GROUP BY a;

After:

SELECT s.a AS a, SUM(s.b) AS b FROM (SELECT 6 AS a, x.b AS b FROM x AS x) AS s GROUP BY s.a;

[github-actions]

SQLGlot Integration Test Results

✅ All tests passed

Comparing:

• this branch (sqlglot:optimizer/bug-literal-group-projection @ sqlglot d15d606)
• baseline (main @ sqlglot 122b44f)

Overall

main: 192416 total, 153532 passed (pass rate: 79.8%)

sqlglot:optimizer/bug-literal-group-projection: 180222 total, 142385 passed (pass rate: 79.0%)

Transitions:
No change

Dialect pair changes: 0 previous results not found, 3 current results not found

✅ All tests passed

[georgesittas]

Tried optimizing this query as well

-- Input
WITH c AS (SELECT DISTINCT x.b AS b FROM x)
SELECT s.a, SUM(s.b) AS b FROM (SELECT 6 AS a, b FROM c) AS s CROSS JOIN x GROUP BY s.a

-- Optimized under this PR
WITH c AS (...) SELECT 6 AS a, SUM(c.b) AS b FROM c CROSS JOIN x GROUP BY a

The GROUP BY now binds a to x.a from the outer cross join. Seems like a similar bug. Additionally, there appears to be a similar bug with ORDER BY on a non-projected literal alias:

-- input
SELECT SUM(s.b) AS b FROM (SELECT 6 AS a, b FROM x) AS s GROUP BY s.a ORDER BY s.a

-- Optimized
SELECT SUM(x.b) AS b FROM x AS x GROUP BY a ORDER BY 6

This is also problematic, but let's address it separately to avoid scope creep.

[georgesittas]

We should be careful not to walk selects / expressions more than needed. This can be wasteful if repeated without care. It's worth looking into refactoring this.

[fivetran-kwoodbeck]

I'm not sure we can get around this one.

[georgesittas]

Similarly, these find / find_all calls can result in walking many nodes. There are other places where they happen in _mergeable. We should make sure we're not repeating a lot of work.

There may be a better alternative of pre-aggregating everything we need for these checks, but for that we would need to run all the cheap "mergeable" checks first, to avoid taking on the overhead preemptively.

[fivetran-kwoodbeck]

found a way around the find_all

[georgesittas]

What about:

Suggested change

	if isinstance(source, Scope) and grouped & {
	s.alias_or_name for s in source.expression.selects
	}:
	if isinstance(source, Scope) and grouped & set(source.expression.named_selects):