alamb opened a new issue, #7110: URL: https://github.com/apache/arrow-datafusion/issues/7110
### Is your feature request related to a problem or challenge? Right now, DataFusionhas 104 built in functions: https://docs.rs/datafusion/latest/datafusion/logical_expr/enum.BuiltinScalarFunction.html <img width="940" alt="Screenshot 2023-07-27 at 8 51 45 AM" src="https://github.com/apache/arrow-datafusion/assets/490673/6c8c420b-bbba-475f-8e2d-69348d69fe7d";> As we add new features and functions (most recently, `date_diff` https://github.com/apache/arrow-datafusion/issues/7097#issuecomment-1653466104 or all the arary functions) this number will keep growing This growth means that the size of the DataFusion library will keep growing even if users do not use those features ### Describe the solution you'd like Given that DataFusion has all the machinery to register user defined functions, and they are mostly handled the same way, I propose we split up the datafusion built into scalar function packages Perhaps like * `string_functions` (`upper`, `hex`, etc) * `crypto_functions` (`hash`, etc) * `array_functions` (`make_array`, `array_contains`, etc) * date_time functions (`date_trunc`, etc) * ... Not only would this give users better control over their binary size it would also ensure that the extensibility APIs of DataFusion were sufficient for all functions (and we could enhance the extension points if this was not the case) This would replace the existing somewhat haphazard feature flags like `crypto_functions`: https://github.com/apache/arrow-datafusion/blob/11b7b5c215012231e5768fc5be3445c0254d0169/datafusion/physical-expr/src/lib.rs#L21-L22 I would imagine these functions would be in their own crates like `datafusion_functions_crypto` with an entry point like ```rust let ctx = SessionContext::new(); ctx.sql("select hash('foobar')");// would error // register all functions in the `datafusion_functions_crypto` package datafusion_functions_crypto::register(&ctx) ctx.sql("select hash('foobar')");// would now succeed ``` ### Describe alternatives you've considered We could continue to use feature flags If this works out, we could do the same thing for aggregate and window functions ### 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]
