[
https://issues.apache.org/jira/browse/CALCITE-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-3000:
--------------------------------
Summary: Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to
support overload method call (was: Improve SqlUserDefinedFunction and
SqlUserDefinedTableFunction to support override method call)
> Improve SqlUserDefinedFunction and SqlUserDefinedTableFunction to support
> overload method call
> ----------------------------------------------------------------------------------------------
>
> Key: CALCITE-3000
> URL: https://issues.apache.org/jira/browse/CALCITE-3000
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: pengzhiwei
> Assignee: pengzhiwei
> Priority: Major
>
> Currently the ModelHandler adds one Function to the schema for one java
> method. For the scalar function,ModelHandler resolves all the method in the
> class and translate each of them to ScalarFunction to support override method
> call. But for TableFunction, this has not been support yet.
> Maybe we can support it as the scalar function does. However in that way,
> one sql function may match multiple Functions in the schema.I think this is
> not a good way. It is better to have only one Function in the schema for one
> sql function just like the BuildIn operator.
> I'd like to support a new operand type check strategy for
> SqlUserDefinedFunction and SqlUserDefinedTableFunction which can infer the
> operand type and return type according to the input parameter types.
> I will extend the Types#lookupMethod to support finding the best method in
> all of the override methods in a class. And the
> SqlReturnTypeInference、SqlOperandTypeInference and
> SqlOperandTypeChecker can use this to do the type inference according to the
> input types. I think it is a dynamically way compared with the original way.
> Any suggestion is welcomed,thanks!
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
