[FLINK-9294] Improve type inference for UDFs with composite parameter or result type

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Component/s: Table SQL / API
• Labels: auto-unassigned pull-request-available
• Assignee: Unassigned
• Reporter: Rong Rong
• Created: 03/May/18 15:46
• Updated: 30/Apr/21 03:53
• Resolved: 30/Apr/21 03:53

Description

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:

public String[] eval(Map<String, Integer> mapArg) { /* ...  */ }

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

Issue Links

• links to: GitHub Pull Request #6472
• links to: GitHub Pull Request #6472