[
https://issues.apache.org/jira/browse/CALCITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101135#comment-18101135
]
Mihai Budiu commented on CALCITE-7685:
--------------------------------------
What is the benefit of this change? Better performance?
There are some very subtle behaviors when there are multiple matches which may
change.
> 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 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. The default value (true) would wrap its TABLE argument in an
> internal $SCALAR_QUERY call, and validation would then fail error ("Cannot
> apply '$SCALAR_QUERY' ...") instead of the expected arity error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
