[
https://issues.apache.org/jira/browse/CALCITE-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887411#comment-17887411
]
Mihai Budiu commented on CALCITE-6617:
--------------------------------------
Regarding the second issue, there are two problems that contribute to it:
- the query plan before optimization contains an expression like (simplified
version)
A <= 10 OR (A = (DOUBLE)1). Since the type-checked has determined that A is a
DOUBLE, the expression should have been A <= (DOUBLE)10 OR (A = (DOUBLE)1)
- the simplification in RexSimplify code abuses the Comparable interface, using
it without a type argument. The Guava Range is given both BigDecimal and Double
values, but they do not extend the same Comparable<T> for some class T.
I will check to see which one of these is easiest to fix, but both are real
problems.
In general, the RexLiteral class should abstract the type of the value, too
many code fragments poke inside and do various things depending on its actual
type; the getValueAs() method is the problematic one.
> Regression after CALCITE-2067 which gives a ClassCastException
> --------------------------------------------------------------
>
> Key: CALCITE-6617
> URL: https://issues.apache.org/jira/browse/CALCITE-6617
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Claude Brisson
> Assignee: Mihai Budiu
> Priority: Blocker
> Fix For: 1.38.0
>
>
> The following statement:
> {code:java}
> SELECT * FROM (VALUES (1, 2, 3), (5E0::REAL, 5E0, NULL)) AS foo {code}
> will provoke a ClassCastException between a Double and a BigDecimal, while it
> was working in 1.37.0.
> It's due to the fact that when trying to infer a collation on a Values
> tuples, the comparator still assumes that all numbers are of the same class,
> which changed with CALCITE-2067.
> Here is the full stack trace:
>
> {code:java}
> Caused by: java.lang.ClassCastException: class java.lang.Double cannot be
> cast to class java.math.BigDecimal (java.lang.Double and java.math.BigDecimal
> are in module java.base of loader 'bootstrap')
> at java.base/java.math.BigDecimal.compareTo(BigDecimal.java:330)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:45)
> at
> org.apache.calcite.rel.metadata.RelMdCollation$1.compare(RelMdCollation.java:458)
> at
> org.apache.calcite.rel.metadata.RelMdCollation$1.compare(RelMdCollation.java:454)
> at com.google.common.collect.Ordering.isOrdered(Ordering.java:910)
> at
> org.apache.calcite.rel.metadata.RelMdCollation.values(RelMdCollation.java:434)
> at
> org.apache.calcite.rel.logical.LogicalValues.lambda$create$0(LogicalValues.java:111)
> at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:246)
> at
> org.apache.calcite.rel.logical.LogicalValues.create(LogicalValues.java:110)
> at
> org.apache.calcite.rel.core.RelFactories$ValuesFactoryImpl.createValues(RelFactories.java:521)
> at org.apache.calcite.tools.RelBuilder.values(RelBuilder.java:3497)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:2924)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:2946)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertValuesImpl(SqlToRelConverter.java:5050)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2488)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2393)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2355)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:754)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:734)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3905)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:627)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
