osipovartem opened a new pull request, #26158:
URL: https://github.com/apache/datafusion/pull/26158

   ## Which issue does this PR close?
   
   Part of #24860. This covers physical `CaseExpr::return_field`; the logical 
SQL projection path is handled separately by #26145.
   
   ## Rationale for this change
   
   A physical CASE over Arrow extension-typed fields currently returns a plain 
field and loses its extension metadata, even when every result branch agrees. 
That prevents metadata-aware physical consumers from recognizing the result 
type.
   
   ## What changes are included in this PR?
   
   - Preserve metadata when non-NULL result branches agree on type and 
metadata; mismatches conservatively drop it.
   - Resolve nested CASE and cast wrappers bottom-up, avoiding repeated 
formatting and field inference for every suffix of a nested CASE chain.
   - Preserve the common unmarked Column/Literal fast path.
   
   ## What is the testing strategy for this PR?
   
   - New unit tests cover matching/conflicting metadata, NULL and typed-NULL 
branches, nested CAST/TRY_CAST, and a deterministic display-count bound for 
nested CASE planning.
   - `cargo +stable test -p datafusion-physical-expr --lib`: 1,691 passed, 2 
ignored.
   - Full DataFusion extended workspace test command from AGENTS.md: passed 
after initializing the three pinned test-data submodules (including 532 
SQLLogicTest files).
   - `cargo +stable fmt --all --check` and focused `cargo +stable clippy -p 
datafusion-physical-expr --all-targets --all-features -- -D warnings`: passed.
   - Full workspace clippy passed with `-A unfulfilled_lint_expectations`; 
without that allowance, five pre-existing expectations in 
`datafusion-substrait` fail under local Rust 1.98. Rust 1.95 instead reports 
unrelated `from_iter_instead_of_collect` errors in `datafusion-common`.
   - Independent read-only review approved correctness, API compatibility, 
planning cost, and tests.
   
   ## Are there any user-facing changes?
   
   Physical CASE result fields retain Arrow metadata when it is unambiguous. No 
API change. End-to-end SQL projection metadata still requires #26145.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to