[
https://issues.apache.org/jira/browse/CALCITE-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023793#comment-17023793
]
Jin Xing edited comment on CALCITE-2885 at 1/26/20 12:58 PM:
-------------------------------------------------------------
Hi, Ruben ~
I also came across this issue. *FIRST_KNOWN* infers operand types by calling
*deriveType* on operands. In your case (+_select 2 * ? = 4_+), when deriving
operand types for *EQUALS* function, type of the dynamic param in *MULTIPLY* is
not inferred yet, thus the deriving failed for validation[1][2].
To my best knowledge, type validation might be not needed when infer operand
types – – we will do operand type validation anyway after operand type
inference. Currently *SqlOperator#checkOperandTypes* already has a param[3] to
control whether to swallow the exception if type checking failed. I'm thinking
that shall we have a switch to control whether to bypass type validation in
*SqlValidatorImpl#deriveType* ? We can disable the type validation during
operand type inference and enable afterwards. But note that this change is not
trivial – – public methods will be changed to add param for switching.
[1][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L534]
[2][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L448]
[3][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L450]
was (Author: [email protected]):
Hi, Ruben ~
I also came across this issue. *FIRST_KNOWN* infers operand types by calling
*deriveType* on operands. In your case (+_select 2 * ? = 4_+), when deriving
operand types for *EQUALS* function, type of the dynamic param in *MULTIPLY* is
not inferred yet, thus the deriving failed for validation[1][2].
To my best knowledge, type validation might be not needed when infer operand
types – – we will do operand type validation anyway after operand type
inference. I'm thinking that shall we have a switch to control whether to
bypass type validation in *SqlValidatorImpl#deriveType* ? We can disable the
type validation during operand type inference and enable afterwards. But note
that this change is not trivial – – public methods will be changed to add param
for switching.
[1][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L534]
[2][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L448]
> 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 Q L
> 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
(v8.3.4#803005)
