[ 
https://issues.apache.org/jira/browse/CALCITE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Talbot updated CALCITE-5207:
-----------------------------------
    Description: 
>From CALCITE-3914, "canonicalizeNode" attempts to canonicalize any 
>SqlKind.PLUS rexCall. Unfortunately, this includes a 
>`SqlDatetimePlusOperator`. When the canonicalize causes the operand order to 
>reverse, this will result in an exception in the line
{code:java}
rexBuilder.makeCall(call.getOperator(), right, left) {code}
in the operators return type inference (since now operand 1 is a timestamp and 
operand 0 is an interval)
{code:java}
final IntervalSqlType unitType =
    (IntervalSqlType) opBinding.getOperandType(1) {code}
A call like the following should repro when used in tests like those in 
[https://github.com/apache/calcite/commit/ee1a9d2cacb67da4c5d7e8f0441c94a40dc69d66:]
 
{code:java}
final RexNode ts_plus_interval =
        rexBuilder.makeCall(
                SqlStdOperatorTable.DATETIME_PLUS,
                rexBuilder.makeTimestampLiteral(new TimestampString("2018-01-01 
00:00:00"), 0),
                        rexBuilder.makeIntervalLiteral(
                                new BigDecimal(12),
                                new SqlIntervalQualifier(TimeUnit.MONTH, null, 
SqlParserPos.ZERO)
                        )); {code}

  was:
>From CALCITE-3914, "canonicalizeNode" attempts to canonicalize any 
>SqlKind.PLUS rexCall. Unfortunately, this includes a 
>`SqlDatetimePlusOperator`. When the canonicalize causes the operand order to 
>reverse, this will result in an exception in the line
{code:java}
rexBuilder.makeCall(call.getOperator(), right, left) {code}
in the operators return type inference 
{code:java}
final IntervalSqlType unitType =
    (IntervalSqlType) opBinding.getOperandType(1) {code}
A call like the following should repro when used in tests like those in 
https://github.com/apache/calcite/commit/ee1a9d2cacb67da4c5d7e8f0441c94a40dc69d66:
 
{code:java}
final RexNode ts_plus_interval =
        rexBuilder.makeCall(
                SqlStdOperatorTable.DATETIME_PLUS,
                rexBuilder.makeTimestampLiteral(new TimestampString("2018-01-01 
00:00:00"), 0),
                        rexBuilder.makeIntervalLiteral(
                                new BigDecimal(12),
                                new SqlIntervalQualifier(TimeUnit.MONTH, null, 
SqlParserPos.ZERO)
                        )); {code}


> SubstitutionVisitor should not canonicalize DatetimePlus
> --------------------------------------------------------
>
>                 Key: CALCITE-5207
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5207
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Steven Talbot
>            Priority: Major
>
> From CALCITE-3914, "canonicalizeNode" attempts to canonicalize any 
> SqlKind.PLUS rexCall. Unfortunately, this includes a 
> `SqlDatetimePlusOperator`. When the canonicalize causes the operand order to 
> reverse, this will result in an exception in the line
> {code:java}
> rexBuilder.makeCall(call.getOperator(), right, left) {code}
> in the operators return type inference (since now operand 1 is a timestamp 
> and operand 0 is an interval)
> {code:java}
> final IntervalSqlType unitType =
>     (IntervalSqlType) opBinding.getOperandType(1) {code}
> A call like the following should repro when used in tests like those in 
> [https://github.com/apache/calcite/commit/ee1a9d2cacb67da4c5d7e8f0441c94a40dc69d66:]
>  
> {code:java}
> final RexNode ts_plus_interval =
>         rexBuilder.makeCall(
>                 SqlStdOperatorTable.DATETIME_PLUS,
>                 rexBuilder.makeTimestampLiteral(new 
> TimestampString("2018-01-01 00:00:00"), 0),
>                         rexBuilder.makeIntervalLiteral(
>                                 new BigDecimal(12),
>                                 new SqlIntervalQualifier(TimeUnit.MONTH, 
> null, SqlParserPos.ZERO)
>                         )); {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to