james-willis commented on PR #27143: URL: https://github.com/apache/datafusion/pull/27143#issuecomment-6698509535
Thanks Dewey. Integrated all your feedback. **Logical vs physical.** Agreed, this relies on each branch's physical field matching its logical one, which is the property #27156 describes for every expression. CASE derives its field only from its branches in both layers, so it matches whenever its branches do, and a branch that doesn't (NOT in #27155, Alias in #27156) shows through. #26158 avoids that by carrying the logical field into the physical CASE, at the cost of storing it and a protobuf change. In practice the mismatch doesn't change the result schema, which takes its metadata from the logical plan. Only a function that takes the CASE as an argument sees the physical field. in the NOT case probably this doesnt really matter - its probably just extra metadata. In the Alias case it can be an issue but this is probably exceeding rate to call alias on a subexpression that doesnt persist past the operator. `test_case_lowering_preserves_field_metadata` in `physical-expr/src/planner.rs` (8ef340299) now compares `Expr::Case::to_field` with the physical `return_field` for column, literal, cast and nested CASE branches, including a typed NULL ELSE with metadata. **Coercion casts.** Logical and physical agree: the type-only cast that coercion inserts drops the extension type and keeps other keys on both sides. The unit test above covers it, and a new `metadata.slt` case checks that `CASE ... THEN cast(name AS JSON) ELSE arrow_cast(l_name, 'LargeUtf8') END` is `LargeUtf8` without an extension type. -- 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]
