[
https://issues.apache.org/jira/browse/CALCITE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313667#comment-16313667
]
Julian Hyde commented on CALCITE-1658:
--------------------------------------
Can you add the following tests as part of your fix. We don't test
{{cast('yyyy-mm-dd' as timestamp)}} anywhere outside of DruidAdapterIT
currently.
{noformat}
diff --git
a/core/src/test/java/org/apache/calcite/sql/test/SqlOperatorBaseTest.java
b/core/src/test/java/org/apache/calcite/sql/test/SqlOperatorBaseTest.java
index e1c9e9c..19c722d 100644
--- a/core/src/test/java/org/apache/calcite/sql/test/SqlOperatorBaseTest.java
+++ b/core/src/test/java/org/apache/calcite/sql/test/SqlOperatorBaseTest.java
@@ -1320,6 +1320,14 @@ private void checkCastToString(String value, String
type, String expected) {
"cast('1945-02-24 12:42:25.34' as TIMESTAMP)",
"1945-02-24 12:42:25",
"TIMESTAMP(0) NOT NULL");
+ tester.checkScalar(
+ "cast('1945-12-31' as TIMESTAMP)",
+ "1945-12-31 00:00:00",
+ "TIMESTAMP(0) NOT NULL");
+ tester.checkScalar(
+ "cast('2004-02-29' as TIMESTAMP)",
+ "2004-02-29 00:00:00",
+ "TIMESTAMP(0) NOT NULL");
if (Bug.FRG282_FIXED) {
tester.checkScalar(
diff --git a/core/src/test/resources/sql/misc.iq
b/core/src/test/resources/sql/misc.iq
index 9a79bb7..e32ffbf 100644
--- a/core/src/test/resources/sql/misc.iq
+++ b/core/src/test/resources/sql/misc.iq
@@ -1508,7 +1508,7 @@ select (case when (true) then 1 end) from (values(1));
EXPR$0 INTEGER(10)
!type
-# Cast an character literal to a timestamp; note: the plan does not contain
CAST
+# Cast a character literal to a timestamp; note: the plan does not contain CAST
values cast('1969-07-21 12:34:56' as timestamp);
+---------------------+
| EXPR$0 |
@@ -1522,6 +1522,20 @@ EnumerableCalc(expr#0=[{inputs}], expr#1=[1969-07-21
12:34:56], EXPR$0=[$t1])
EnumerableValues(tuples=[[{ 0 }]])
!plan
+# Cast a character literal without time to a timestamp; note: the plan does
not contain CAST
+values cast('1969-07-21' as timestamp);
++---------------------+
+| EXPR$0 |
++---------------------+
+| 1969-07-21 00:00:00 |
++---------------------+
+(1 row)
+
+!ok
+EnumerableCalc(expr#0=[{inputs}], expr#1=[1969-07-21 00:00:00], EXPR$0=[$t1])
+ EnumerableValues(tuples=[[{ 0 }]])
+!plan
+
# Cast a character literal to a date; note: the plan does not contain CAST
values cast('1969-07-21' as date);
+------------+
{noformat}
> DateRangeRules issues
> ---------------------
>
> Key: CALCITE-1658
> URL: https://issues.apache.org/jira/browse/CALCITE-1658
> Project: Calcite
> Issue Type: Bug
> Components: core, druid
> Reporter: Gian Merlino
> Assignee: Nishant Bangarwa
> Fix For: 1.16.0
>
>
> Follow up to CALCITE-1601. In Druid's built in SQL module (not the Druid
> adapter in Calcite), some unit tests fail when DateRangeRules.FILTER_INSTANCE
> is enabled. These include the SQLs below. In all cases, the predicate was
> incorrectly simplified to "false" and no Druid queries were made.
> Removing DateRangeRules from the planner causes the results to be correct.
> {code}
> SELECT COUNT(*) FROM druid.foo
> WHERE
> (EXTRACT(YEAR FROM __time) = 2000 AND EXTRACT(MONTH FROM __time) IN
> (2, 3, 5))
> OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM __time) = 1)
> {code}
> {code}
> SELECT COUNT(*) FROM druid.foo
> WHERE
> EXTRACT(YEAR FROM __time) IN (2000, 2001) AND ( (EXTRACT(YEAR FROM
> __time) = 2000 AND EXTRACT(MONTH FROM __time) IN (2, 3, 5))
> OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM __time) = 1)
> )
> {code}
> {code}
> SELECT COUNT(*) FROM druid.foo
> WHERE
> EXTRACT(YEAR FROM __time) <> 2000 AND ( (EXTRACT(YEAR FROM __time) =
> 2000 AND EXTRACT(MONTH FROM __time) IN (2, 3, 5))
> OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM __time) = 1)
> )
> {code}
> {code}
> SELECT COUNT(*) FROM druid.foo
> WHERE
> EXTRACT(MONTH FROM __time) IN (1, 2, 3, 5) AND ( (EXTRACT(YEAR FROM
> __time) = 2000 AND EXTRACT(MONTH FROM __time) IN (2, 3, 5))
> OR (EXTRACT(YEAR FROM __time) = 2001 AND EXTRACT(MONTH FROM __time) = 1)
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
