[jira] [Updated] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6007:
Labels: pull-request-available (was: )
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768229#comment-17768229
]
Wenrui Meng commented on CALCITE-6007:
--
Yes. The proposed solution is basically make it work the same way as how SELECT
sub-query work.
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6005) POLYGON string representation has changed on Apple silicon
[
https://issues.apache.org/jira/browse/CALCITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-6005.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[cc73aba9|https://github.com/apache/calcite/commit/cc73aba9b4af0c3af5ac96422518a821e951cb9b].
In this change we solve the problem by changing replacing the floating point
values with their x86_64 values. After this change the tests pass on both CPU
architectures. If the problem spreads beyond a couple of tests we can adopt a
more robust solution.
> POLYGON string representation has changed on Apple silicon
> --
>
> Key: CALCITE-6005
> URL: https://issues.apache.org/jira/browse/CALCITE-6005
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
> Fix For: 1.36.0
>
>
> I am getting a test error when I run RelOptRulesTest on JDK 19 and Apple
> silicon (Apple M1 chip, arm64 architecture).
> {noformat}
> $ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
> core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
> ---
> /Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
>2023-09-13 11:52:04
> +++
> /Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
>2023-09-13 12:08:52
> @@ -14044,7 +14044,7 @@
>
>
>
> @@ -14173,7 +14173,7 @@
>
>
>
>
> {noformat}
> It's a little hard to see, but the number "4.45672280493228" has changed to
> "4.456722804932279". My hypothesis is that this is because
> [JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in
> JDK 19.
> I believe that the new value is more "correct". However, we will still need
> to run the test on old JDKs. So we need to find a way to run the new
> double-to-string algorithm on older JDKs, or mask out the result in tests.
> The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
> happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
> occurs on Apple silicon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6005) POLYGON string representation has changed on Apple silicon
[
https://issues.apache.org/jira/browse/CALCITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-6005:
Assignee: Julian Hyde
> POLYGON string representation has changed on Apple silicon
> --
>
> Key: CALCITE-6005
> URL: https://issues.apache.org/jira/browse/CALCITE-6005
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.36.0
>
>
> I am getting a test error when I run RelOptRulesTest on JDK 19 and Apple
> silicon (Apple M1 chip, arm64 architecture).
> {noformat}
> $ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
> core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
> ---
> /Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
>2023-09-13 11:52:04
> +++
> /Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
>2023-09-13 12:08:52
> @@ -14044,7 +14044,7 @@
>
>
>
> @@ -14173,7 +14173,7 @@
>
>
>
>
> {noformat}
> It's a little hard to see, but the number "4.45672280493228" has changed to
> "4.456722804932279". My hypothesis is that this is because
> [JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in
> JDK 19.
> I believe that the new value is more "correct". However, we will still need
> to run the test on old JDKs. So we need to find a way to run the new
> double-to-string algorithm on older JDKs, or mask out the result in tests.
> The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
> happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
> occurs on Apple silicon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5990) Explicit cast to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768190#comment-17768190
]
Runkang He commented on CALCITE-5990:
-
[~libenchao] Yes, this is a regression. I have updated the jira's info.
> Explicit cast to numeric type doesn't check overflow
>
>
> Key: CALCITE-5990
> URL: https://issues.apache.org/jira/browse/CALCITE-5990
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Blocker
> Fix For: 1.36.0
>
>
> Explicit cast to numeric type doesn't check overflow, and this issue can be
> reproduced by sqlline:
> {code:sql}
> select cast(empno as tinyint), cast(130 as tinyint) from emps where
> name='Alice'; -- empno is 130
> {code}
> The empno is INT type. The result is:
> {code:sql}
> -126, -126{code}
> I think it should throw exception when overflow.
> At last, this issue was found when to turn on runtime check for
> CalciteSqlOperatorTest in CALCITE-5921.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5990) Explicit cast to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Runkang He updated CALCITE-5990:
Fix Version/s: 1.36.0
> Explicit cast to numeric type doesn't check overflow
>
>
> Key: CALCITE-5990
> URL: https://issues.apache.org/jira/browse/CALCITE-5990
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Blocker
> Fix For: 1.36.0
>
>
> Explicit cast to numeric type doesn't check overflow, and this issue can be
> reproduced by sqlline:
> {code:sql}
> select cast(empno as tinyint), cast(130 as tinyint) from emps where
> name='Alice'; -- empno is 130
> {code}
> The empno is INT type. The result is:
> {code:sql}
> -126, -126{code}
> I think it should throw exception when overflow.
> At last, this issue was found when to turn on runtime check for
> CalciteSqlOperatorTest in CALCITE-5921.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5990) Explicit cast to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Runkang He updated CALCITE-5990:
Priority: Blocker (was: Major)
> Explicit cast to numeric type doesn't check overflow
>
>
> Key: CALCITE-5990
> URL: https://issues.apache.org/jira/browse/CALCITE-5990
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Blocker
>
> Explicit cast to numeric type doesn't check overflow, and this issue can be
> reproduced by sqlline:
> {code:sql}
> select cast(empno as tinyint), cast(130 as tinyint) from emps where
> name='Alice'; -- empno is 130
> {code}
> The empno is INT type. The result is:
> {code:sql}
> -126, -126{code}
> I think it should throw exception when overflow.
> At last, this issue was found when to turn on runtime check for
> CalciteSqlOperatorTest in CALCITE-5921.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6005) POLYGON string representation has changed on Apple silicon
[
https://issues.apache.org/jira/browse/CALCITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6005:
-
Description:
I am getting a test error when I run RelOptRulesTest on JDK 19 and Apple
silicon (Apple M1 chip, arm64 architecture).
{noformat}
$ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
---
/Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
2023-09-13 11:52:04
+++
/Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
2023-09-13 12:08:52
@@ -14044,7 +14044,7 @@
@@ -14173,7 +14173,7 @@
{noformat}
It's a little hard to see, but the number "4.45672280493228" has changed to
"4.456722804932279". My hypothesis is that this is because
[JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in JDK
19.
I believe that the new value is more "correct". However, we will still need to
run the test on old JDKs. So we need to find a way to run the new
double-to-string algorithm on older JDKs, or mask out the result in tests.
The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
occurs on Apple silicon.
was:
I am getting a test error when I run RelOptRulesTest on JDK 19 and ARM (Apple
M1).
{noformat}
$ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
---
/Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
2023-09-13 11:52:04
+++
/Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
2023-09-13 12:08:52
@@ -14044,7 +14044,7 @@
@@ -14173,7 +14173,7 @@
{noformat}
It's a little hard to see, but the number "4.45672280493228" has changed to
"4.456722804932279". My hypothesis is that this is because
[JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in JDK
19.
I believe that the new value is more "correct". However, we will still need to
run the test on old JDKs. So we need to find a way to run the new
double-to-string algorithm on older JDKs, or mask out the result in tests.
The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
occurs on Apple silicon.
> POLYGON string representation has changed on Apple silicon
> --
>
> Key: CALCITE-6005
> URL: https://issues.apache.org/jira/browse/CALCITE-6005
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
>
> I am getting a test error when I run RelOptRulesTest on JDK 19 and Apple
> silicon (Apple M1 chip, arm64 architecture).
> {noformat}
> $ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
> core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
> ---
> /Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
>2023-09-13 11:52:04
> +++
> /Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
>2023-09-13 12:08:52
> @@ -14044,7 +14044,7 @@
>
>
>
> @@ -14173,7 +14173,7 @@
>
>
>
>
> {noformat}
> It's a little hard to see, but the number "4.45672280493228" has changed to
> "4.456722804932279". My hypothesis is that this is because
> [JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in
> JDK 19.
> I believe that the new value is more "correct". However, we will still need
> to run the test on old JDKs. So we need to find a way to run the new
> double-to-string algorithm on older JDKs, or mask out the result in tests.
> The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
> happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
> occurs on Apple silicon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6005) POLYGON string representation has changed on Apple silicon
[
https://issues.apache.org/jira/browse/CALCITE-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6005:
-
Summary: POLYGON string representation has changed on Apple silicon (was:
POLYGON string representation has changed in JDK 19)
> POLYGON string representation has changed on Apple silicon
> --
>
> Key: CALCITE-6005
> URL: https://issues.apache.org/jira/browse/CALCITE-6005
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
>
> I am getting a test error when I run RelOptRulesTest on JDK 19 and ARM (Apple
> M1).
> {noformat}
> $ diff -u core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
> core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
> ---
> /Users/julianhyde/dev/calcite.1/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
>2023-09-13 11:52:04
> +++
> /Users/julianhyde/dev/calcite.1/core/build/diffrepo/test/org/apache/calcite/test/RelOptRulesTest_actual.xml
>2023-09-13 12:08:52
> @@ -14044,7 +14044,7 @@
>
>
>
> @@ -14173,7 +14173,7 @@
>
>
>
>
> {noformat}
> It's a little hard to see, but the number "4.45672280493228" has changed to
> "4.456722804932279". My hypothesis is that this is because
> [JDK-4511638|https://bugs.openjdk.org/browse/JDK-4511638] has been fixed in
> JDK 19.
> I believe that the new value is more "correct". However, we will still need
> to run the test on old JDKs. So we need to find a way to run the new
> double-to-string algorithm on older JDKs, or mask out the result in tests.
> The bug seems to require both Apple silicon (ARM) and JDK 19. (It doesn't
> happen on Intel JDK 19 or ARM JDK 11.) I am a little confused that it only
> occurs on Apple silicon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768187#comment-17768187 ] Runkang He commented on CALCITE-5957: - [~zstan] This can be splited to another jira. For current issue, we need to fix regression. If you don't mind, I would take this issue to continue. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Priority: Blocker > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5987) SqlImplementor loses type information for literals
[
https://issues.apache.org/jira/browse/CALCITE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768183#comment-17768183
]
Julian Hyde commented on CALCITE-5987:
--
I agree this might be useful. You are correct that not every SQL constant can
be simply represented as a literal, and types such as {{VARCHAR}} and
{{VARBINARY}} are cases in point.
> SqlImplementor loses type information for literals
> --
>
> Key: CALCITE-5987
> URL: https://issues.apache.org/jira/browse/CALCITE-5987
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> When converting a SqlNode to a String query, the conversion can produce SQL
> that computes different results. This happens because literals do not carry
> type information in the result string. For example, this plan:
> {code}
> rel#7:LogicalValues.(type=RecordType(VARCHAR(3) EXPR$0),tuples=[{ 'A' }])
> {code}
> will generate a SQL query:
> {code}
> SELECT 'A'
> {code}
> While the type of the former result is VARCHAR(3), the latter query produces
> a CHAR(1) result.
> It would be nice if SqlImplementor had an option to produce a query that
> preserves the output type, e.g.:
> {code}
> SELECT (CAST 'A' as VARCHAR(3))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768178#comment-17768178
]
Julian Hyde commented on CALCITE-6007:
--
I'm saying make it work the same way as existing code, and I don't have time to
figure out how the existing code does it.
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6023) Possible bug found in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768177#comment-17768177
]
Julian Hyde commented on CALCITE-6023:
--
A query similar to yours works just fine:
{noformat}
diff --git a/core/src/test/resources/sql/winagg.iq
b/core/src/test/resources/sql/winagg.iq
index 7304a00382..f1ce24e40a 100644
--- a/core/src/test/resources/sql/winagg.iq
+++ b/core/src/test/resources/sql/winagg.iq
@@ -98,6 +98,20 @@ order by 1;
!ok
+select deptno, lead(count(*), -1) over (order by deptno) as x
+from emp
+group by deptno;
+++---+
+| DEPTNO | X |
+++---+
+| 10 | |
+| 20 | 3 |
+| 30 | 5 |
+++---+
+(3 rows)
+
+!ok
+ {noformat}
I think the problem is that you are calling the parser and sql-to-rel-converter
by hand and maybe not calling the validator.
Please change the summary to describe the minimum repro. "Possible bug found in
Calcite" could describe all of our bugs. :)
> Possible bug found in SqlToRelConverter
> ---
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> ```
> UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall:
> LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> ```
> SQL:
> ```
> SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"
> ```
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6024) ListSqlOperatorTable is inefficient
Julian Hyde created CALCITE-6024:
Summary: ListSqlOperatorTable is inefficient
Key: CALCITE-6024
URL: https://issues.apache.org/jira/browse/CALCITE-6024
Project: Calcite
Issue Type: Improvement
Reporter: Julian Hyde
{{ListSqlOperatorTable}} is inefficient if it contains a large number of
operators. It currently examines the operators one by one.
{{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
builds a map of operators by name (actually two maps, one case-sensitive and
one case-insensitive).
{{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768150#comment-17768150
]
Julian Hyde commented on CALCITE-6021:
--
I have a partial fix in
[6021-datetime|https://github.com/julianhyde/calcite/tree/6021-datetime].
The {{lookupOperatorOverloads}} methods in {{ListSqlOperatorTable}} and
{{ReflectiveSqlOperatorTable}} treat syntax inconsistently. (One uses
{{instanceof SqlFunction}}, and another checks {{SqlSyntax.family}}.) That
needs to be fixed. Can you finish the job, [~tanclary]?
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768134#comment-17768134
]
Tanner Clary commented on CALCITE-6021:
---
[~julianhyde] Whoops just saw your most recent comment, sounds good.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768133#comment-17768133
]
Tanner Clary commented on CALCITE-6021:
---
[~julianhyde] Sorry I may have highlighted the wrong test, even when the
conformance and library are both set for BigQuery, it does not allow the
function to work with parentheses. It throws the error: {{Column
'CURRENT_DATETIME' not found in any table}} . I will look more into
{{SqlSyntax.FUNCTION_ID}}, though.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768130#comment-17768130
]
Julian Hyde commented on CALCITE-6021:
--
Setting the syntax didn't fix the problem. For some reason
{{SqlValidator.makeNullaryCall(SqlIdentifier id)}} is still not doing the right
thing. Looking into it.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768125#comment-17768125
]
Julian Hyde commented on CALCITE-6021:
--
The test you have highlighted, {{{}SqlValidatorTest.testCurrentDatetime{}}},
should and does correctly fail. The BigQuery operator table is not enabled, and
therefore the validator can't find the {{CURRENT_DATETIME}} function.
There should be another test that {{SELECT CURRENT_DATETIME}} is valid if you
use the BQ parser and operator table.
The variable {{expectedError}} is not used in that test and should be removed.
It is confusing for maintainers.
Somewhere - I'm not sure where - we should specify that {{CURRENT_DATETIME}}
does not use parentheses when there are zero arguments, but does allow
arguments. {{SqlSyntax.FUNCTION_ID}} is probably it.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768106#comment-17768106
]
Tanner Clary commented on CALCITE-5955:
---
[~julianhyde] If you are trying to parse a query like {{SELECT
PERCENTILE_CONT(users.age, .5) OVER(PARTITION BY users.id)}} would this not
qualify as a window function? This is considered valid according to BigQuery's
syntax.
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768095#comment-17768095
]
Tanner Clary edited comment on CALCITE-6021 at 9/22/23 5:03 PM:
Hey [~julianhyde], [~jswett] do either of you remember from [CALCITE-4297] why
{{CURRENT_DATETIME}} was not fully allowed as a niladic function (test for
clarity:
[ac96eb8|https://github.com/apache/calcite/commit/ac96ebc5009e781a31503288adf292000b80#diff-a85b0fc0f75ac484ae9307e3a5eb51f1275833bd81051c247f52a95406784ddcR1506].)
From what I can tell, it has something to do with it being a library operator
(to test, I moved the PI operator into the library operator table and it began
failing with similar errors). Any light either of you could shed on that would
be great. Thanks!
was (Author: JIRAUSER298151):
Hey [~julianhyde], [~jswett] do either of you remember from [CALCITE-4297] why
{{CURRENT_DATETIME}} was not fully allowed as a niladic function (test for
clarity:
[ac96eb8|https://github.com/apache/calcite/commit/ac96ebc5009e781a31503288adf292000b80#diff-a85b0fc0f75ac484ae9307e3a5eb51f1275833bd81051c247f52a95406784ddcR1506].
From what I can tell, it has something to do with it being a library operator
(to test, I moved the PI operator into the library operator table and it began
failing with similar errors). Any light either of you could shed on that would
be great. Thanks!
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768095#comment-17768095
]
Tanner Clary commented on CALCITE-6021:
---
Hey [~julianhyde], [~jswett] do either of you remember from [CALCITE-4297] why
{{CURRENT_DATETIME}} was not fully allowed as a niladic function (test for
clarity:
[ac96eb8|https://github.com/apache/calcite/commit/ac96ebc5009e781a31503288adf292000b80#diff-a85b0fc0f75ac484ae9307e3a5eb51f1275833bd81051c247f52a95406784ddcR1506].
From what I can tell, it has something to do with it being a library operator
(to test, I moved the PI operator into the library operator table and it began
failing with similar errors). Any light either of you could shed on that would
be great. Thanks!
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768078#comment-17768078 ] Ran Tao edited comment on CALCITE-5737 at 9/22/23 4:33 PM: --- Hi, devs. I noticed that the JDK 21 has been released. Considering JDK 21 is a LTS version, IMHO, It would be better if calcite skips JDK 20 and supports JDK 21 in our future releases. [https://openjdk.org/projects/jdk/21/] was (Author: lemonjing): Hi, devs. I noticed that the JDK 21 has been released. Considering JDK 21 is a LTS version, IMHO, if calcite skip JDK 20 and support JDK 21 in our future version will be better. [https://openjdk.org/projects/jdk/21/] > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768078#comment-17768078 ] Ran Tao edited comment on CALCITE-5737 at 9/22/23 4:32 PM: --- Hi, devs. I noticed that the JDK 21 has been released. Considering JDK 21 is a LTS version, IMHO, if calcite skip JDK 20 and support JDK 21 in our future version will be better. [https://openjdk.org/projects/jdk/21/] was (Author: lemonjing): Hi, I noticed that the JDK 21 has been released. Considering JDK 21 is a LTS version, IMHO, if calcite skip JDK 20 and support JDK 21 in our future version will be better. [https://openjdk.org/projects/jdk/21/|https://openjdk.org/projects/jdk/21/] > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768078#comment-17768078 ] Ran Tao commented on CALCITE-5737: -- Hi, I noticed that the JDK 21 has been released. Considering JDK 21 is a LTS version, IMHO, if calcite skip JDK 20 and support JDK 21 in our future version will be better. [https://openjdk.org/projects/jdk/21/|https://openjdk.org/projects/jdk/21/] > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5971) Add the RelRule to rewrite the bernoulli sample as Filter
[
https://issues.apache.org/jira/browse/CALCITE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5971:
--
Description:
For the following SQL:
{code:java}
select deptno from "scott".dept tablesample bernoulli(50); {code}
We could rewrite it to:
{code:java}
select deptno from "scott".dept where rand() < 0.5; {code}
The sql :
{code:java}
select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
{code}
We could rewrite it to:
{code:java}
select deptno from "scott".dept where rand(10) < 0.5; {code}
This rule only rewrite the tablesample bernoulli,and this rule is like
presto/trino's
[ImplementBernoulliSampleAsFilter|https://github.com/prestodb/presto/blob/6eef062bdd3777936fa29127e728edde86a681d4/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/ImplementBernoulliSampleAsFilter.java#L47C1-L48C35]
rule
was:
For the following SQL:
{code:java}
select deptno from "scott".dept tablesample bernoulli(50); {code}
We could rewrite it to:
{code:java}
select deptno from "scott".dept where rand() < 0.5; {code}
The sql :
{code:java}
select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
{code}
We could rewrite it to:
{code:java}
select deptno from "scott".dept where rand(10) < 0.5; {code}
This rule only rewrite the tablesample bernoulli.
> Add the RelRule to rewrite the bernoulli sample as Filter
> --
>
> Key: CALCITE-5971
> URL: https://issues.apache.org/jira/browse/CALCITE-5971
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Fix For: 1.36.0
>
>
> For the following SQL:
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50); {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand() < 0.5; {code}
> The sql :
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
> {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand(10) < 0.5; {code}
> This rule only rewrite the tablesample bernoulli,and this rule is like
> presto/trino's
> [ImplementBernoulliSampleAsFilter|https://github.com/prestodb/presto/blob/6eef062bdd3777936fa29127e728edde86a681d4/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/ImplementBernoulliSampleAsFilter.java#L47C1-L48C35]
> rule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5971) Add the RelRule to rewrite the bernoulli sample as Filter
[
https://issues.apache.org/jira/browse/CALCITE-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768061#comment-17768061
]
LakeShen commented on CALCITE-5971:
---
Could someone help me review this pr?
> Add the RelRule to rewrite the bernoulli sample as Filter
> --
>
> Key: CALCITE-5971
> URL: https://issues.apache.org/jira/browse/CALCITE-5971
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Fix For: 1.36.0
>
>
> For the following SQL:
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50); {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand() < 0.5; {code}
> The sql :
> {code:java}
> select deptno from "scott".dept tablesample bernoulli(50) REPEATABLE(10);
> {code}
> We could rewrite it to:
> {code:java}
> select deptno from "scott".dept where rand(10) < 0.5; {code}
> This rule only rewrite the tablesample bernoulli.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5994) Add optimization rule to remove Sort when its input's row number is less or equal to one
[
https://issues.apache.org/jira/browse/CALCITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5994:
--
Issue Type: New Feature (was: Improvement)
> Add optimization rule to remove Sort when its input's row number is less or
> equal to one
>
>
> Key: CALCITE-5994
> URL: https://issues.apache.org/jira/browse/CALCITE-5994
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort's input source max row numer is 1,then we could remove the
> redundant Sort,the Sort could be a sorted semantic Sort(offset and fetch is
> null).
> For example,the sql:
> {code:java}
> select * from (select * from tableA limit 1) order by c ;
> {code}
> because the `(select * from tableA limit 1) ` max row number is 1, then we
> could remove order by c
> {code:java}
> select * from tableA limit 1;
> {code}
> The sql:
> {code:java}
> select max(totalprice) from orders order by 1 {code}
> could converted to:
> {code:java}
> select max(totalprice) from orders{code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantSort|https://github.com/prestodb/presto/blob/c21fc28846252cd910d90f046514bf586d7bb5c6/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantSort.java#L27]
> rule:
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768060#comment-17768060
]
LakeShen commented on CALCITE-6011:
---
This PR is Ready, the PR link is : [https://github.com/apache/calcite/pull/3439]
if others have time, please help me to review it, thank you very much:)
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6011:
--
Fix Version/s: 1.36.0
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6011:
Labels: pull-request-available (was: )
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6023) Possible bug found in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768057#comment-17768057
]
Tanner Clary edited comment on CALCITE-6023 at 9/22/23 3:17 PM:
Hi [~jfhannel], thanks for filing this case! Would you mind updating the title
to be a bit more specific/descriptive of the problem? Also if you want to
format something as code you can surround it with {{ like:
{{ some code here }}
was (Author: JIRAUSER298151):
Hi [~jfhannel], thanks for filing this case! Would you mind updating the title
to be a bit more specific/descriptive? Also if you want to format something as
code you can surround it with {{ like:
{{ some code here }}
> Possible bug found in SqlToRelConverter
> ---
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> ```
> UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall:
> LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> ```
> SQL:
> ```
> SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"
> ```
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6023) Possible bug found in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768057#comment-17768057
]
Tanner Clary edited comment on CALCITE-6023 at 9/22/23 3:16 PM:
Hi [~jfhannel], thanks for filing this case! Would you mind updating the title
to be a bit more specific/descriptive? Also if you want to format something as
code you can surround it with {{ like:
{{ some code here }}
was (Author: JIRAUSER298151):
Hi [~jfhannel], thanks for filing this case! Would you mind updating the title
to be a bit more specific/descriptive? Also if you want to format something as
code you can either surround it with {{ or use {code:java} (and close with }}
or {code})
> Possible bug found in SqlToRelConverter
> ---
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> ```
> UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall:
> LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> ```
> SQL:
> ```
> SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"
> ```
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6023) Possible bug found in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768057#comment-17768057
]
Tanner Clary commented on CALCITE-6023:
---
Hi [~jfhannel], thanks for filing this case! Would you mind updating the title
to be a bit more specific/descriptive? Also if you want to format something as
code you can either surround it with {{ or use {code:java} (and close with }}
or {code})
> Possible bug found in SqlToRelConverter
> ---
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> ```
> UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall:
> LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> ```
> SQL:
> ```
> SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"
> ```
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6011:
--
Component/s: core
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6023) Possible bug found in SqlToRelConverter
Jordan Hannel created CALCITE-6023: -- Summary: Possible bug found in SqlToRelConverter Key: CALCITE-6023 URL: https://issues.apache.org/jira/browse/CALCITE-6023 Project: Calcite Issue Type: Bug Affects Versions: 1.35.0 Reporter: Jordan Hannel Attachments: stacktrace.txt Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and repro are outlined below, and the full stacktrace is attached. This is on calcite version 1.35.0. Any insight would be much appreciated, thanks! When I parse the below SQL string to get a SqlNode, and call SqlToRelConverter.convertQuery on this SqlNode, I get error: ``` UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`) ``` SQL: ``` SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0" GROUP BY "dim4" ``` I have confirmed that my SqlToRelConverter instance seems generally ok, because it is able to convert many other SqlNodes to RelNodes. After some experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is translated to a RelNode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5990) Explicit cast to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767959#comment-17767959
]
Benchao Li commented on CALCITE-5990:
-
[~Runking] Does this mean that this is an regression? If yes, let's mark the
fixVersion = 1.36, and priority = blocker, we need to fix it in 1.36.0
> Explicit cast to numeric type doesn't check overflow
>
>
> Key: CALCITE-5990
> URL: https://issues.apache.org/jira/browse/CALCITE-5990
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
>
> Explicit cast to numeric type doesn't check overflow, and this issue can be
> reproduced by sqlline:
> {code:sql}
> select cast(empno as tinyint), cast(130 as tinyint) from emps where
> name='Alice'; -- empno is 130
> {code}
> The empno is INT type. The result is:
> {code:sql}
> -126, -126{code}
> I think it should throw exception when overflow.
> At last, this issue was found when to turn on runtime check for
> CalciteSqlOperatorTest in CALCITE-5921.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL
[
https://issues.apache.org/jira/browse/CALCITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-6022:
Description:
"CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
postgresql, sparksql) support it. So I think it is worth implementing.syntax:
{code:sql}
CREATE TABLE [IF NOT EXISTS] table_name
LIKE source_table [ like_option ... ]{code}
And for the `like_option`, I think the syntax of postgreSQL is more flexible
and powerful, and I believe it is reasonable to be similar to postgreSQL. But
there are not so many attributes in calcite, just keep CONSTRAINTS DEFAULTS and
ALL.
{code:sql}
{ INCLUDING | EXCLUDING } { CONSTRAINTS | DEFAULTS | ALL }{code}
Some related link:
[https://www.postgresql.org/docs/current/sql-createtable.html]
[https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
[https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
was:
"CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
postgresql, sparksql) support it. So I think it is worth implementing.
syntax:
{code:java}
CREATE TABLE [IF NOT EXISTS] table_name
LIKE source_table [ like_option ... ]{code}
And for the `like_option`, I think the syntax of postgreSQL is more flexible
and powerful, and I believe it is reasonable to be similar to postgreSQL. But
there are not so many attributes in calcite, just keep CONSTRAINTS DEFAULTS and
ALL.
{code:java}
{ INCLUDING | EXCLUDING } { CONSTRAINTS | DEFAULTS | ALL }{code}
Some related link
[https://www.postgresql.org/docs/current/sql-createtable.html]
[https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
[https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
> Support "CREATE TABLE ... LIKE" DDL
> ---
>
> Key: CALCITE-6022
> URL: https://issues.apache.org/jira/browse/CALCITE-6022
> Project: Calcite
> Issue Type: New Feature
> Components: server
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> "CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
> postgresql, sparksql) support it. So I think it is worth implementing.syntax:
> {code:sql}
> CREATE TABLE [IF NOT EXISTS] table_name
> LIKE source_table [ like_option ... ]{code}
> And for the `like_option`, I think the syntax of postgreSQL is more flexible
> and powerful, and I believe it is reasonable to be similar to postgreSQL. But
> there are not so many attributes in calcite, just keep CONSTRAINTS DEFAULTS
> and ALL.
> {code:sql}
> { INCLUDING | EXCLUDING } { CONSTRAINTS | DEFAULTS | ALL }{code}
> Some related link:
> [https://www.postgresql.org/docs/current/sql-createtable.html]
> [https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
> [https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL
[
https://issues.apache.org/jira/browse/CALCITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo reassigned CALCITE-6022:
---
Assignee: hongyu guo
> Support "CREATE TABLE ... LIKE" DDL
> ---
>
> Key: CALCITE-6022
> URL: https://issues.apache.org/jira/browse/CALCITE-6022
> Project: Calcite
> Issue Type: New Feature
> Components: server
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> "CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
> postgresql, sparksql) support it. So I think it is worth implementing.syntax:
> {code:sql}
> CREATE TABLE [IF NOT EXISTS] table_name
> LIKE source_table [ like_option ... ]{code}
> And for the `like_option`, I think the syntax of postgreSQL is more flexible
> and powerful, and I believe it is reasonable to be similar to postgreSQL. But
> there are not so many attributes in calcite, just keep CONSTRAINTS DEFAULTS
> and ALL.
> {code:sql}
> { INCLUDING | EXCLUDING } { CONSTRAINTS | DEFAULTS | ALL }{code}
> Some related link:
> [https://www.postgresql.org/docs/current/sql-createtable.html]
> [https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
> [https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6022) Support "CREATE TABLE ... LIKE" DDL
hongyu guo created CALCITE-6022:
---
Summary: Support "CREATE TABLE ... LIKE" DDL
Key: CALCITE-6022
URL: https://issues.apache.org/jira/browse/CALCITE-6022
Project: Calcite
Issue Type: New Feature
Components: server
Affects Versions: 1.35.0
Reporter: hongyu guo
Fix For: 1.36.0
"CREATE TABLE ... LIKE" is SQL standard syntax, and some other dbms(mysql,
postgresql, sparksql) support it. So I think it is worth implementing.
syntax:
{code:java}
CREATE TABLE [IF NOT EXISTS] table_name
LIKE source_table [ like_option ... ]{code}
And for the `like_option`, I think the syntax of postgreSQL is more flexible
and powerful, and I believe it is reasonable to be similar to postgreSQL. But
there are not so many attributes in calcite, just keep CONSTRAINTS DEFAULTS and
ALL.
{code:java}
{ INCLUDING | EXCLUDING } { CONSTRAINTS | DEFAULTS | ALL }{code}
Some related link
[https://www.postgresql.org/docs/current/sql-createtable.html]
[https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#table%20definition]
[https://dev.mysql.com/doc/refman/8.0/en/create-table-like.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5976) Use explicit casting if inserted element type in ArrayPrepend/ArrayAppend/ArrayInsert does not equal derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5976:
-
Summary: Use explicit casting if inserted element type in
ArrayPrepend/ArrayAppend/ArrayInsert does not equal derived component type
(was: The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit
casting when element type not equals derived component type)
> Use explicit casting if inserted element type in
> ArrayPrepend/ArrayAppend/ArrayInsert does not equal derived component type
> ---
>
> Key: CALCITE-5976
> URL: https://issues.apache.org/jira/browse/CALCITE-5976
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> array_prepend(array[1], cast(2 as tinyint));
> array_append(array[1], cast(2 as tinyint)) {code}
> {noformat}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer (java.lang.Byte and java.lang.Integer are in module
> java.base of loader 'bootstrap')
>
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
> at
> org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
>
[jira] [Updated] (CALCITE-5948) Use explicit casting if element type in ARRAY/MAP does not equal derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Summary: Use explicit casting if element type in ARRAY/MAP does not equal
derived component type (was: Explicit casting should be made if the type of an
element in ARRAY/MAP not equals the derived component type)
> Use explicit casting if element type in ARRAY/MAP does not equal derived
> component type
> ---
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer). However, this function validate success in
> calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
>
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not;
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must
> be of the same type]
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
> {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
> public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
> --> we need explicit cast here
> return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
