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

Julian Hyde commented on CALCITE-7451:
--------------------------------------

I would be fine if we just removed it. (Deprecated for one release, I guess.)

> REINTERPRET should not be used in logical plans
> -----------------------------------------------
>
>                 Key: CALCITE-7451
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7451
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.41.0
>            Reporter: Mihai Budiu
>            Priority: Minor
>
> This one may not be easy to fix.
> Calcite has a version of a cast named REINTERPRET.
> Here is the documentation from SqlStdOperatorTable:
> {code:java}
>   /**
>    * An <code>REINTERPRET</code> operator is internal to the planner. When the
>    * physical storage of two types is the same, this operator may be used to
>    * reinterpret values of one type as the other. This operator is similar to
>    * a cast, except that it does not alter the data value. Like a regular cast
>    * it accepts one operand and stores the target type as the return type. It
>    * performs an overflow check if it has <i>any</i> second operand, whether
>    * true or not.
>    */
>   public static final SqlSpecialOperator REINTERPRET =
>       new SqlSpecialOperator("Reinterpret", SqlKind.REINTERPRET) {
>         @Override public SqlOperandCountRange getOperandCountRange() {
>           return SqlOperandCountRanges.between(1, 2);
>         }
>       };{code}
> As the documentation says, this should only be used when the physical size is 
> known. However, in logical plans the physical size is not known.
> This cast is introduced by RexBuilder in the conversion from Sql to Rel, via 
> the SqlRexConvertletTable. That is very early in the compilation process, in 
> a layer which should know nothing about physical sizes.
> I have seen this cast used mostly for converting intervals to integers; this 
> assumes that the cast knows the representation of intervals. But this layer 
> has no business assuming a representation for the intervals, that's for much 
> later in the compilation process. Intervals could be represented, for 
> example, as DECIMAL values, or perhaps as a long number of nanoseconds.
> This code seems to be there since 2012.



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

Reply via email to