paleolimbot opened a new pull request, #22162: URL: https://github.com/apache/datafusion/pull/22162
## Which issue does this PR close? - Closes #22079 ## Rationale for this change The logical `Expr::Cast` and `Expr::TryCast` have a `FieldRef` target that was added in https://github.com/apache/datafusion/pull/18136 so that logical casts can express a cast to an extension type. In combination with a SQL type planner ( https://github.com/apache/datafusion/pull/20676 ) and an optimizer rule, this enabled casting to/from extension types with custom semantics to actually occur. The ability to do this was reverted by https://github.com/apache/datafusion/pull/20836 (which removed the original test) and I am not sure that ability ever made it into a release. ## What changes are included in this PR? This PR strips specific metadata keys (extension name and extension metadata) when propagating metadata from the source of a cast to the target (because doing so may result in an invalid destination field that consumers could reject), and propagates all metadata from the (logical) cast target field (e.g., so that a cast to an extension type represented by the cast target field will have a `to_field()` that communicates the extension type). For the physical cast, this PR strips the extension name and metadata keys from the source field for the default cast (i.e., where the target field of the physical cast is just a DataType). This is needed so that the logical and physical behaviour agrees. The physical cast's target field comes from the logical cast's target field, so the extra metadata added by the logical cast field is already there. In the planner, I re-added the behaviour where a cast to an extension type is rejected with an error. Casting to an extension type can be implemented with an optimizer rule, planner, or by the mechanism I have in the works in https://github.com/apache/datafusion/pull/21071 . I would prefer to strip metadata across a cast (as we do for scalar function calls) but released DataFusions all currently do this and so this workaround is perhaps less disruptive. ## Are these changes tested? Yes ## Are there any user-facing changes? It was in practice not common to create a `Expr::Cast` with field metadata internally and thus I don't think users will see metadata changes from the inclusion of metadata from the target field. I would be surprised if stripping the extension name/metadata from the source was disruptive (it was more likely to have caused errors). -- 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]
