vibhatha commented on pull request #12590:
URL: https://github.com/apache/arrow/pull/12590#issuecomment-1084498299
> @vibhatha I'm not entirely clear on the concern. I don't mind if we have
an inheritence tree of object structs. For example, this would be ok (this is
totally made up and likely is not correct for aggregate UDFs at all):
>
> ```
> struct UdfOptions {
> cp::Function::Kind kind;
> cp::Arity arity;
> const cp::FunctionDoc func_doc;
> std::vector<cp::InputType> in_types;
> cp::OutputType out_type;
> cp::MemAllocation::type mem_allocation;
> cp::NullHandling::type null_handling;
> };
>
> struct ScalarUdfOptions : public UdfOptions {
> std::string func_name;
> };
>
> struct AggregateUdfOptions : public UdfOptions {
> std::string init_func_name;
> std::string map_func_name;
> std::string reduce_func_name;
> };
>
> Status MakeScalarFunction(PyObject* function, const ScalarUdfOptions&
options);
> Status MakeAggregateFunction(PyObject* function, const
AggregateUdfOptions& options);
> ```
@westonpace This make sense to me. How about if we have to go for dynamic
content, where we have to attach those values from Python to this struct. I
haven't explored this deeply, that's why I mentioned that part is yet to be
implemented. I am not 100% sure if we need such an option, but yet to verify
it's necessity.
--
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]
