[
https://issues.apache.org/jira/browse/CALCITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-7685:
------------------------------------
Labels: pull-request-available (was: )
> Filter unresolved function overloads by argument count during early resolution
> ------------------------------------------------------------------------------
>
> Key: CALCITE-7685
> URL: https://issues.apache.org/jira/browse/CALCITE-7685
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.42.0
> Reporter: Dmitry Sysolyatin
> Assignee: Dmitry Sysolyatin
> Priority: Minor
> Labels: pull-request-available
>
> During early resolution of a not-yet-resolved function call
> (SqlUnresolvedFunction), the validator looks up operator overloads by name
> only, without checking the number of arguments.
> The lookup could also filter overloads by the call's operand count. A call
> whose arity matches no overload stays unresolved; the validator later
> resolves it as usual and reports an arity error:
> {code:sql}
> SELECT deptno FROM emp ORDER BY group_id(deptno);
> -- before: GROUP_ID operator may only occur in an aggregate query
> -- after: Invalid number of arguments to function 'GROUP_ID'. Was expecting
> 0 arguments
> {code}
> As part of this change, SqlUnresolvedFunction#argumentMustBeScalar must
> return false. With arity filtering, a wrong-arity call to a table function
> such as TUMBLE stays unresolved at the point where sub-queries are
> registered, and the default value (true) would wrap its TABLE argument in a
> scalar sub-query before resolution, causing the eventual arity error to lose
> its source position.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
