[
https://issues.apache.org/jira/browse/FLINK-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16554866#comment-16554866
]
Rong Rong commented on FLINK-9294:
----------------------------------
Had an initial diff for discussion on what needs to be done here:
[https://github.com/walterddr/flink/compare/f60aa6e72ca860bb30730472c0c7db8fef500e5c...b8b9c62c2f0226517aee661fb3d8332bdf7dedb8]
Seems like with some recent relaxation in the UDF lookup, all of the above
mentioned problems are fixed and can be used correctly. The only remaining
problem is: Too much relaxation causes incorrect runtime exception.
I can go ahead and close this task by commit the test changes and continue the
work in FLINK-9501.
Any thoughts and concerns?
> Improve type inference for UDFs with composite parameter or result type
> ------------------------------------------------------------------------
>
> Key: FLINK-9294
> URL: https://issues.apache.org/jira/browse/FLINK-9294
> Project: Flink
> Issue Type: Sub-task
> Components: Table API & SQL
> Reporter: Rong Rong
> Assignee: Rong Rong
> Priority: Major
>
> Most of the UDF function signatures that includes composite types such as
> *{{MAP}}*, *{{ARRAY}}*, etc would require user to override
> *{{getParameterType}}* or *{{getResultType}}* method explicitly.
> It should be able to resolve the composite type based on the function
> signature, such as:
> {code:java}
> public String[] eval(Map<String, Integer> mapArg) { /* ... */ }
> {code}
> The function catalog search should do either of the following:
> [Update]
> since we have backward compatibility issue with resolving to a different
> type, we will not go with the modify type option.
> - -Automatically resolve that:-
> -1. *{{ObjectArrayTypeInfo<BasicTypeInfo.STRING>}}* to be the result type.-
> -2. *{{MapTypeInfo<BasicTypeInfo.STRING, BasicTypeInfo.INTEGER>}}* to be the
> parameter type.-
> - Improved function mapping to find and locate function with such signatures
>
> [Update]
> This ticket should only cover *Map* and *Row* type, It does not cover
> * ObjectArrayType, since Array is actually resolved by eval method signature
> correctly.
> * Pojo types, Pojo will be addressed separately.
> This ticket should consolidate some discrepancy between how TableFunction,
> AggregateFunction and ScalarFunction resolves types. which at this moment
> goes through different code path.
> The rest of the optimization should go to follow up tickets in FLINK-9484
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
