Unwrap widening Date32 -> Date64 casts in comparison predicates

[adriangb]

Which issue does this PR close?

• N/A. Small, self-contained enhancement to unwrap_cast_in_comparison; happy to file a tracking issue if preferred.

Rationale for this change

unwrap_cast_in_comparison could not unwrap a cast between the two date types, so a predicate like CAST(date32_col AS Date64) <op> <date64 literal> never folded onto the bare column. Folding it lets the literal be compared against the unmodified column, keeping predicate pushdown / pruning effective on date columns.

There were two coupled causes in try_cast_literal_to_type (datafusion/expr-common/src/casts.rs):

1. try_cast_numeric_literal scaled both Date32 and Date64 literals by the same target multiplier (mul = 1). But Date32 counts days since the epoch while Date64 counts milliseconds, so a cross conversion needs a factor of MILLISECONDS_IN_DAY (86_400_000).
2. is_lossy_temporal_cast classified every Date <-> temporal pair as lossy, which swept in Date32 <-> Date64 and blocked the unwrap outright.

The reverse direction is subtle and unsound if handled naively: narrowing a Date64 column down to Date32 truncates milliseconds to the day (many-to-one), so CAST(date64 AS Date32) = <day> matches any millisecond within that day. arrow-rs does not require Date64 values to be whole-day (apache/arrow-rs#5288), so the column may carry sub-day values the planner cannot see, and unwrapping would drop those rows. That direction is therefore explicitly blocked.

What changes are included in this PR?

• Relax is_lossy_temporal_cast so a date-to-date (and identity) cast is not pre-classified as lossy; per-value exactness is enforced downstream.
• Add scale_date_literal with exact-only semantics: Date32 -> Date64 multiplies by MILLISECONDS_IN_DAY (overflow-guarded with checked arithmetic); Date64 -> Date32 divides only on a whole-day boundary and otherwise returns None. This mirrors the existing Decimal scaling path in the same function.
• Add is_date_narrowing_cast and block the narrowing Date64 -> Date32 column cast in the two logical-optimizer gates (comparison and in-list) and in the physical-expr simplifier, mirroring is_timestamp_precision_narrowing_cast. The physical-expr guard is required for soundness on the pruning / row-group-filter path (verified by a unit test that fails without it); the widening Date32 -> Date64 column cast is injective and stays supported.

Scope is intentionally limited to Date32 <-> Date64 scaling, the narrowing gate, and tests.

Are these changes tested?

Yes, at two levels.

End-to-end (datafusion/sqllogictest/test_files/simplify_expr.slt) — the PR is structured as three commits so the behavior change is legible in the diff:

1. test: characterizes current behavior (passes on unmodified main): neither direction is unwrapped, results are correct. The fixture stores sub-day and pre-epoch Date64 values on purpose.
2. feat: applies only the code change; the recorded widening EXPLAIN plans now fail intentionally.
3. test: regenerates the expectations. The commit-3 diff is exactly the widening plans flipping from CAST(d32 AS Date64) <op> Date64(..) to d32 <op> Date32(..); every result row and every narrowing plan is byte-identical, which is the soundness proof. Coverage includes =/</<=/>/>=/IN, whole-day vs sub-day literals (the latter yields zero rows and is left as-is), the narrowing soundness case (the noon row is still returned), pre-epoch dates (arrow's toward-zero truncation is pinned), and NULL three-valued logic.

Unit — scale_date_literal exactness and i32::MIN/i32::MAX overflow, is_date_narrowing_cast, the relaxed is_lossy_temporal_cast date-pair behavior, and the physical-expr narrowing guard.

cargo fmt --check is clean, cargo clippy -p datafusion-expr-common -- -D warnings passes, and the full sqllogictest suite passes.

Are there any user-facing changes?

No public API changes. The optimizer now additionally rewrites widening Date32 -> Date64 cast comparisons where it previously left them untouched; results are unchanged, plans are simplified. Narrowing Date64 -> Date32 cast comparisons are deliberately left as-is.

Note for reviewers

The open PR #23727 adds the if from_type == to_type { return false } identity guard to this same function. This PR is based independently on main and includes that identity line as part of the clean gate shape here, so depending on merge order the two may need a trivial rebase where those lines overlap.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.78%. Comparing base (0f2e137) to head (91255d3).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23729      +/-   ##
==========================================
+ Coverage   80.77%   80.78%   +0.01%     
==========================================
  Files        1089     1089              
  Lines      368938   369200     +262     
  Branches   368938   369200     +262     
==========================================
+ Hits       297992   298246     +254     
- Misses      53197    53199       +2     
- Partials    17749    17755       +6     

☔ 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.

[adriangb]

@kosiew wonder if you could help take a look at this change?

[kosiew]

@adriangb

Looks good overall. I did not find any blocking issues. I left one small suggestion to strengthen the Date-specific test coverage.

[kosiew]

Could we add one widening comparison with the Date64 literal on the left, for example <date64 literal> < CAST(d32 AS Date64)? It would be useful to verify that logical simplification moves the column to the left and swaps the operator correctly. The existing cases cover the new conversion behavior with the cast on the left, while this would add Date-specific coverage for the reversed-operand path. The physical operator-swap path already has generic unit coverage.

[adriangb]

Added 73ff3d1

[adriangb]

@kosiew noting that we are removing this test (which was just added in #23727 by you and I) because this PR unblocks this. This is expected since I found these two things together but wanted to fix them independently and not couple them.

[adriangb]

@kosiew I rebased and resolved conflcits with #23727, leaving a note in #23729 (comment) about the conflicts. Could you take a look and leave confirmation that you're still 👍🏻 on this change before I merge it?

[kosiew]

@adriangb
This iteration looks good to me too.