[
https://issues.apache.org/jira/browse/CALCITE-7451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068523#comment-18068523
]
Julian Hyde commented on CALCITE-7451:
--------------------------------------
I don't think I ever fully understood REINTERPRET. If it is for things like
converting a signed 32 bit int to an unsigned 32 bit int, maybe we can
introduce a function in each case.
> 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)
