[
https://issues.apache.org/jira/browse/CALCITE-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781526#comment-16781526
]
Ruben Quesada Lopez edited comment on CALCITE-2885 at 3/1/19 10:04 AM:
-----------------------------------------------------------------------
I think what is happening here is that the SqlOperandTypeInference FIRST_KNOWN
of the equals function tries to infer its parameters' type evaluating its
operands and taking the first "non-unknown" type. In our second test (the one
which fails), it will try to get the type from the MULTIPLY function using
callBinding.getValidator().deriveType(callBinding.getScope(), operand). This
deriveType will eventually call the MULTIPLY validateOperands method, and since
there is an unknown parameter (the dynamic one), it will fail.
If we reverse the equality, as in the first test, the problem does not happen
because the SqlOperandTypeInference FIRST_KNOWN will never call the MULTIPLY
derive type, since it will break before as soon as it derived the type from the
numeric literal. Right after, the SqlValidatorImpl will call inferUnknownTypes
for the equals' operands (which was not called in the previous case), and that
was the key, because that method will infer and store the dynamic parameter's
type inside the SqlValidatorImpl nodeToTypeMap; and later, the MULTIPLY
operands validation will not fail.
Thus, it would seem that in the second test we get to an unlucky situation
where the execution order of the validation of the different items is not the
appropriate one.
was (Author: rubenql):
I think what is happening here is that the SqlOperandTypeInference FIRST_KNOWN
of the equals function would try to infer its parameters' type evaluating its
operands and taking the first "non-unknown" type. In our second test (the one
which fails), it would try to get the type from the MULTIPLY function using
callBinding.getValidator().deriveType(callBinding.getScope(), operand). This
deriveType will eventually call the MULTIPLY validateOperands method, and since
there is an unknown parameter (the dynamic one), it will fail.
If we reversed the equality, as in the first test, the problem did not happen
because the SqlOperandTypeInference FIRST_KNOWN will never call the MULTIPLY
derive type, since it will break before as soon as it derived the type from the
numeric literal. Right after, the SqlValidatorImpl will call inferUnknownTypes
for the equals' operands (which was not called in the previous case), and that
was the key, because that method will infer and store inside the nodeToTypeMap
the dynamic parameter's type; and later, the MULTIPLY operands validation will
not fail.
> SqlValidatorImpl fails when processing an InferTypes.FIRST_KNOWN function
> containing a function with a dynamic parameter as first operand
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2885
> URL: https://issues.apache.org/jira/browse/CALCITE-2885
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.18.0
> Reporter: Ruben Quesada Lopez
> Priority: Major
>
> Problem can be reproduced by adding following tests (e.g. to
> SqlValidatorDynamicTest.java):
> {code:java}
> @Test public void testDynamicParameter1() throws Exception {
> final String sql = "select 4 = 2*?";
> sql(sql).ok();
> }
> @Test public void testDynamicParameter2() throws Exception {
> final String sql = "select 2*? = 4";
> sql(sql).ok();
> }
> {code}
> The first test will run successfully, but the second one (which is the same
> query reversing the equality operands) will fail with the exception:
> {code}
> org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply '*' to
> arguments of type '<INTEGER> * <UNKNOWN>'. Supported form(s): '<NUMERIC> *
> <NUMERIC>' '<DATETIME_INTERVAL> * <NUMERIC>' '<NUMERIC> *
> <DATETIME_INTERVAL>'
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
