[
https://issues.apache.org/jira/browse/FLINK-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502920#comment-16502920
]
Timo Walther commented on FLINK-9294:
-------------------------------------
The problem why we don't extract {{MapTypeInfo<BasicTypeInfo.STRING,
BasicTypeInfo.INTEGER>}} is because we use the {{TypeExtractor}} for extracting
the type information. Because of historical reasons the type extractor will
return a {{GenericTypeInfo}} for maps. In theory it is possible to extract the
correct type information but this would break backwards compatibility. A
feature that could solve this problem is to allow to register a
{{TypeInfoFactory}} in the type extractor using a Java service loader approach.
Another solution would be to implement our own type extraction stack in
{{flink-table}}.
> 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}
> should either
> 1. Automatically resolve that:
> - *{{ObjectArrayTypeInfo<BasicTypeInfo.STRING>}}* to be the result type.
> - *{{MapTypeInfo<BasicTypeInfo.STRING, BasicTypeInfo.INTEGER>}}* to be the
> parameter type.
> 2. Improved function mapping to find and locate function with such signatures.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
