[jira] [Comment Edited] (CALCITE-2885) SqlValidatorImpl fails when processing an InferTypes.FIRST_KNOWN function containing a function with a dynamic parameter as first operand

["Jin Xing (Jira)" <ji...@apache.org>]

    [ 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: jinxing6042@126.com):
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)