You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have math functions declared as UDFs that while they can be evaluated against float32 and float64, their return type is fixed (float64).
This issue is about extending the UDF interface to support generic return types (a function), so that developers (us included), can register UDFs or variable return types.
There is a small overhead in this, since evaluating types now requires a function call, however, IMO this is still very small when compared to anything, as we are talking about plans. We can always apply some caching if needed.
Currently, we have math functions declared as UDFs that while they can be evaluated against float32 and float64, their return type is fixed (float64).
This issue is about extending the UDF interface to support generic return types (a function), so that developers (us included), can register UDFs or variable return types.
There is a small overhead in this, since evaluating types now requires a function call, however, IMO this is still very small when compared to anything, as we are talking about plans. We can always apply some caching if needed.
Reporter: Jorge Leitão / @jorgecarleitao
Assignee: Jorge Leitão / @jorgecarleitao
PRs and other links:
Note: This issue was originally created as ARROW-9756. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: