[
https://issues.apache.org/jira/browse/CALCITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104567#comment-18104567
]
Mihai Budiu commented on CALCITE-7685:
--------------------------------------
> Could you elaborate on which subtle behaviors with multiple matches you have
> in mind?
I don't have a handy reproduction, but I remember troubleshooting problems
related to case matching. The code for validating a function takes a different
path for validation in the case there is exactly one match and in the case
there are two or more matches, and it may end up rejecting validation for
functions that are clearly in one of the loaded libraries. I think that for
multiple matches is actually uses the argument types to disambiguate in some
way.
So perhaps you can produce some unit tests with functions that normalize to the
same name but have different uppercase/lowercase spellings and signatures?
> 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)
