Ideally, we probably should not have added invoke_batch but unfortunately we released it in
12470
With a deprecation message telling users to migrate from invoke / invoke_no_args to invoke_batch
Ideally we want to move everyone to invoke_with_args, but if we did so at this time, it would force downstream crates to migrate twice in quick succession, which is non ideal.
Describe the solution you'd like
Rather than immediately deprecate invoke_batch and force another confusing upgrade, I propose we leave invoke_batch and invoke_with_args for several releases to allow downstream crates to update.
Describe alternatives you've considered
Then in a few months (maybe DataFusion 46, or 47) we can deprecate invoke_batch and move everything to invoke_with_args
Is your feature request related to a problem or challenge?
The current state of the invoke signature for
ScalarUDFImplis somewhat confusing. AfterWe will have 4 functions
ScalarUDFImpl::invoke(deprecated, only args)ScalarUDFImpl::invoke_no_args(deprecated, only row counts)ScalarUDFImpl::invoke_batch(has row counts and args)ScalarUDFImpl::invoke_with_args(added to support https://github.com/apache/datafusion/issues/12819, has a structure that has arguments, row counts, and return types)Ideally, we probably should not have added
invoke_batchbut unfortunately we released it in12470
With a deprecation message telling users to migrate from
invoke/invoke_no_argstoinvoke_batchIdeally we want to move everyone to
invoke_with_args, but if we did so at this time, it would force downstream crates to migrate twice in quick succession, which is non ideal.Describe the solution you'd like
Rather than immediately deprecate
invoke_batchand force another confusing upgrade, I propose we leaveinvoke_batchandinvoke_with_argsfor several releases to allow downstream crates to update.Describe alternatives you've considered
Then in a few months (maybe DataFusion 46, or 47) we can deprecate
invoke_batchand move everything toinvoke_with_argsAdditional context
No response