mach-kernel commented on issue #17379: URL: https://github.com/apache/datafusion/issues/17379#issuecomment-3393389784
> Maybe @mach-kernel has thoughts on any strengths or limitations to their approach vs the suggestion from @alamb on enhancing the ScalarFunctionArgs. I think you can do both. In our fork we implemented this with a metadata key alongside the literal: https://github.com/spiceai/datafusion/blob/a10e8274a8d2705d349ef8ab9ae31b308405574d/datafusion/sql/src/expr/function.rs#L568-L571 As an example: ```sql select my_fn('abc', def => 'ghi') ``` Ends up percolating all the way through to `ScalarUDFImpl::invoke_with_args`: ```rust ScalarFunctionArgs { args: [ Scalar(Utf8("abc")), Scalar(Utf8("ghi")), ], arg_fields: [ Field { name: "lit", data_type: Utf8, nullable: false, dict_id: 0, dict_is_ordered: false, metadata: {}, }, Field { name: "lit", data_type: Utf8, nullable: false, dict_id: 0, dict_is_ordered: false, metadata: { "spice.parameter_name": "def", }, }, ], ... } ``` To improve usability I can see something like this zipping up the values using the field meta: ```rust pub fn named_args(&self) -> Option<HashMap<String, ColumnarValue>>; ``` We did the metadata approach because it was quick and not invasive. A more invasive approach could be something like introducing `Expr::NamedLiteral`? It could work like how `Expr::Alias` does but with a value instead of an expr. -- 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]
