alamb opened a new issue, #14296: URL: https://github.com/apache/datafusion/issues/14296
### Is your feature request related to a problem or challenge? Coercion is (TODO find definition) At the moment DataFusion has one set of built in coercion rules. However, with a single set of coercion rules, we'll always end up with conflicting requirements such as - https://github.com/apache/datafusion/pull/14223 - https://github.com/apache/datafusion/issues/14272 - https://github.com/apache/datafusion/issues/14230 from @shehabgamin It also makes it hard, as @findepi has pointed out several times, to extend DataFusion with new data types / logica types. My conclusion is we will never be able to have the behavior that works for everyone, and any change in coercion is likely to make some other tradeoff. Rather than having to go back/forth in the core, I think an API would give us an escape hatch. ### Describe the solution you'd like While the user can in theory supply their own coercion rules by adding a new `AnalyzerRule` instead of the current [`TypeCoercion`] rule https://github.com/apache/datafusion/blob/18f14abf3fcef11f014f42e1f0cb8cdc35f257a3/datafusion/optimizer/src/analyzer/type_coercion.rs#L62 I think the coercion code is called in so many places this would only be a partial fix Is it a crazy idea if we tried to implement "user defined coercion rules" -- that way we can have whatever coercion rules are in the DataFusion core but when they inevitably are not quite what users want It would also force us to design the type coercion APIs more coherently which I think would be good for the code quality in general ### Describe alternatives you've considered I was imagining something like ```rust struct MyCoercer {} /// Implement custom coercion ehre impl TypeCoercion for MyCoercer { ... } // register coercion rules like let ctx: SessionContext = SessionStateBuilder::new() .with_type_coercion_rules(Arc::new(MyCoercer{})); ... ``` The trait might look like ```rust /// Defines coercion rules pub trait TypeCoercion { /// Given the types of arguments to a comparison operation (`=`, `<`, etc) what single type should all arguments be cast to fn coerce_comparison(args: &[DataType]) -> DataType ; ... } ``` Maybe there should be methods for `Field` instead of `DataType` 🤔 ### Additional context _No response_ -- 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]
