[
https://issues.apache.org/jira/browse/ARROW-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612864#comment-17612864
]
Joris Van den Bossche commented on ARROW-16211:
-----------------------------------------------
[~rtpsw] the test cases you link to are only about registering functions in
nested registries, I think? But how would you use this in practice? You
mentioned that in the CallFunction API, one can specify the registry to use
through ExecContext.
But that seems not very practical that you need to remember for each function
in which registry it lives to ensure you pass the correct one when calling it.
Also, that's only when you call it manually with CallFunction. But what if the
UDF is part of a larger expression with multiple kernels that thus come from
different registries. How do such things work? Does C++ automatically search
the parent registry as well (that part is not really clear to me)?
In general having to keep track of registries and passing those, just to mimic
the ability to re-register a UDF, seems quite complex. But I am wondering, for
this specific case, wouldn't it be possible to allow to override an existing
name when registering a kernel? It seems in C++ there is already a
{{allow_overwrite}} option when adding functions, this could be exposed to the
Python register function?
> [C++][Python] Unregister compute functions
> ------------------------------------------
>
> Key: ARROW-16211
> URL: https://issues.apache.org/jira/browse/ARROW-16211
> Project: Apache Arrow
> Issue Type: Sub-task
> Components: C++, Python
> Reporter: Vibhatha Lakmal Abeykoon
> Assignee: Vibhatha Lakmal Abeykoon
> Priority: Major
>
> In general, when using UDFs, the user defines a function expecting a
> particular outcome. When building the program, there needs to be a way to
> update existing function kernels if it expands beyond what is planned before.
> In such situations, there should be a way to remove the existing definition
> and add a new definition. To enable this, the unregister functionality has to
> be included.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
