[
https://issues.apache.org/jira/browse/CALCITE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sysolyatin updated CALCITE-7685:
---------------------------------------
Description:
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, 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.
was:
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.
> 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, 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)
