Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.37.0
Description
This is a left-over issue from CALCITE-6617
A reproduction is the following test that can be added to SqlOperatorTest.
This reproduction was created by rubenql.
@Test void differentTypeValues() { CalciteAssert.that() .with(CalciteConnectionProperty.LEX, Lex.JAVA) .with(CalciteConnectionProperty.FORCE_DECORRELATE, false) .withSchema("s", new ReflectiveSchema(new HrSchema())) .query("SELECT * FROM (VALUES (1, 2, 3), (CAST(5E0 AS REAL), 5E0, NULL))") .explainContains("PLAN=EnumerableValues(tuples=[[{ 1.0E0, 2.0E0, 3 }, " + "{ 5.0E0, 5.0E0, null }]])") .returnsOrdered("EXPR$0=1.0; EXPR$1=2.0; EXPR$2=3", "EXPR$0=5.0; EXPR$1=5.0; EXPR$2=null"); }
The underlying problem is the fact that RelBuilder can create an instance of LogicalValues with multiple "rows" where each row has a different type. Although RelBuilder computes the unifying type, this type is actually never used in the construction of the LogicalValues to cast the literals that form the Values.
Attachments
Issue Links
- is related to
-
CALCITE-6617 TypeCoercion is not applied correctly to comparisons
- Closed
- links to