[jira] [Commented] (CALCITE-4397) StandardConvertletTable#convertDatetimeMinus is inconsistent with MINUS_DATE return type inference

["Julian Hyde (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230835#comment-17230835 ] 

Julian Hyde commented on CALCITE-4397:
--------------------------------------

There are a few cases where the {{SqlCall}} has different numbers of operands than the {{RexCall}}. {{SqlReturnTypeInference}}, {{SqlOperandTypeChecker}} etc. all operate at the {{SqlNode}} level, so have no bearing on {{RexCall}}.

So, {{RexBuilder.makeCall}} is making an invalid assumption. Maybe we can give it more information - e.g. a flag so say whether the {{RexCall}} operands line up with the {{SqlCall}} operands. (I have wanted this extra metadata for some time: the nearest we have is have {{SqlOperator.validateRexOperands}}; in a few cases that method unconditionally returns false, to indicate that the operator is not valid in Rex-land.)

Or, just add a caveat to {{makeCall}}'s javadoc.

> StandardConvertletTable#convertDatetimeMinus is inconsistent with MINUS_DATE return type inference
> --------------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-4397
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4397
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.26.0
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> SqlNode representation has 3 parameters: {{datetime}} - {{datetime}} {{interval_qualifier}}
> The return type inference is {{ARG2_NULLABLE}} so it assumes the call has three parameters.
> In practice, {{convertDatetimeMinus}} removes the last parameter via {{rexBuilder.makeCall(resType, op, exprs.subList(0, 2));}}, which blocks node cloning via {{rexBuilder.makeCall(e.getOperator(), operands)}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)