fix: preserve computed projections in unions_to_filter

[pushnanashi2]

Which issue does this PR close?

• Closes unions_to_filter drops computed projections and returns wrong results #25071

Rationale for this change

With enable_unions_to_filter enabled, UNION DISTINCT branches containing different computed projections below their filters can be incorrectly treated as equivalent. This produces wrong result values and row counts without an error.

What changes are included in this PR?

unions_to_filter now skips the rewrite when a projection appears below a branch filter. Alias nodes remain safe to strip. A regression test covers branches computing a + 100 and a + 200 below their filters.

What is the testing strategy for this PR?

• cargo +1.97.0-x86_64-pc-windows-gnullvm test --locked -p datafusion-optimizer unions_to_filter --lib (9 passed)
• The standalone reproducer returns [1100, 1200] with the optimizer setting both disabled and enabled after the fix.
• git diff --check

Are there any user-facing changes?

This prevents incorrect query results when the opt-in unions_to_filter optimizer rule is enabled.

[kumarUjjawal]

Thank you @pushnanashi2 for the fix. I have left few comment for you. Please take a look. Some slt test would also be nice to have.

[kumarUjjawal]

Removing SubqueryAlias has the same defect you just fixed for projections? SELECT x.a FROM t AS x WHERE x.a = 1 UNION SELECT x.a FROM t AS x WHERE x.a = 2 plans as a filter over the alias over TableScan: t, so the merged predicate still names x.a while the source only exposes t.a.

We should trip nothing and take the filter input as the source. GroupKey equality then keeps different projections apart and still merges identical ones, so views and derived tables keep the rewrite instead of losing it. That source needs the volatility test that the wrappers already get.

[pushnanashi2]

Thanks, keeping the filter input intact makes sense. I’ll update the implementation and add tests over the next day or two.

I’ll also check whether different underlying sources with otherwise identical scan metadata can end up in the same GroupKey, since TableScan::eq does not compare source. I haven’t reproduced this yet; I’ll investigate and report back.

[kumarUjjawal]

peel_wrappers already consumed every Projection and SubqueryAlias before this match, so the plan that reaches this arm can never be either one.

strip_passthrough_nodes returns Some on the first iteration here, and the new debug message cannot fire. I would use other directly as the source.

[pushnanashi2]

Thanks for pointing this out. You're right: after peel_wrappers, other cannot be a Projection or SubqueryAlias, so strip_passthrough_nodes always returns Some(other) here. I’ll use other directly as the source and remove the redundant check and unreachable debug message

[codecov-commenter]

Codecov Report

❌ Patch coverage is 66.66667% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.74%. Comparing base (a5c809f) to head (56f24c4).

Files with missing lines	Patch %	Lines
datafusion/optimizer/src/unions_to_filter.rs	66.66%	2 Missing and 15 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #25074      +/-   ##
==========================================
- Coverage   81.74%   81.74%   -0.01%     
==========================================
  Files        1128     1128              
  Lines      416644   416682      +38     
  Branches   416644   416682      +38     
==========================================
+ Hits       340592   340606      +14     
- Misses      55995    56003       +8     
- Partials    20057    20073      +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.