[
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:11 AM:
-----------------------------------------------------------------------
I think what is happening here is that, during
SqlValidatorImpl#inferUnknownTypes execution, 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 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.
> 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)
