Thanks Fabian & Timo for the comments and suggestions.
I agree we should go step-by-step to enable these functionalities.
I will start to consider & fill in the implementation part and create
umbrella tickets.
Best,
Rong
On Tue, May 15, 2018 at 6:54 AM, Timo Walther wrote:
> I added some comme
I added some comments to your documents. I think we should work on these
limitations step by step. A first step could be to support Map?> by considering only the raw types. Another step would be to allow
eval(Object) as a wild card for operands.
Regards,
Timo
Am 14.05.18 um 18:23 schrieb Rong
Thanks for the reply Timo / Fabian,
Yes that's what I had in mind. ParameterType can be vague but return type
has to be exact.
I can image that: depending on the input parameter type, the output type
can be different. But I cannot think of a concrete use cases as of now.
I actually created a doc
Hi Rong,
yes I think we can improve the type infererence at this point. Input
parameter type inference can be more tolerant but return types should be
as exact as possible.
The change should only touch ScalarSqlFunction and
UserDefinedFunctionUtils#createEvalOperandTypeInference, right?
Re
Hi Rong,
I didn't look into the details of the example that you provided, but I
think if we can improve the internal type resolution of scalar UDFs we
should definitely go for it.
There is quite a bit of information available such as the signatures of the
eval() methods but also the argument types
Hi,
We have been looking into more intelligent UDF supports such as creating a
better type inference module to infer automatically composite data
types[1].
One most comment pain point we have are some use cases where users would
like to re-use a rather generic UDF, for example:
public List eval(
