[jira] [Updated] (CALCITE-5810) SUBSTRING compile-time evaluation gives wrong result for large lengths
[
https://issues.apache.org/jira/browse/CALCITE-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5810:
Labels: pull-request-available (was: )
> SUBSTRING compile-time evaluation gives wrong result for large lengths
> --
>
> Key: CALCITE-5810
> URL: https://issues.apache.org/jira/browse/CALCITE-5810
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> This program
> {code:sql}
> SELECT SUBSTRING('string' FROM 2 FOR 2147483646)
> {code}
> returns "" instead of "tring".
> This happens because of an overflow in the SqlFunctions substring function:
> {code:java}
> public static String substring(String c, int s, int l) {
> int lc = c.length();
> int e = s + l; // OVERFLOW here
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5810) SUBSTRING compile-time evaluation gives wrong result for large lengths
Mihai Budiu created CALCITE-5810:
Summary: SUBSTRING compile-time evaluation gives wrong result for
large lengths
Key: CALCITE-5810
URL: https://issues.apache.org/jira/browse/CALCITE-5810
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.34.0
Reporter: Mihai Budiu
This program
{code:sql}
SELECT SUBSTRING('string' FROM 2 FOR 2147483646)
{code}
returns "" instead of "tring".
This happens because of an overflow in the SqlFunctions substring function:
{code:java}
public static String substring(String c, int s, int l) {
int lc = c.length();
int e = s + l; // OVERFLOW here
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5681) Support authorization via GRANT and REVOKE DDL commands
[
https://issues.apache.org/jira/browse/CALCITE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738352#comment-17738352
]
hongyu guo edited comment on CALCITE-5681 at 6/29/23 3:30 AM:
--
[postgres grant sql|https://www.postgresql.org/docs/current/sql-grant.html]
I actually followed the syntax used in Postgres ({{{}ALL TABLES IN SCHEMA{}}}).
And using wildcards like
{code:java}
grant select on s.* to user{code}
is not supported in Postgres.
was (Author: JIRAUSER300840):
[postgres grant sql|https://www.postgresql.org/docs/current/sql-grant.html]
I actually followed the syntax used in Postgres ({{{}ALL TABLES IN SCHEMA{}}}).
And using wildcards like {{}}
{code:java}
grant select on s.* to user{code}
{{}}
is not supported in Postgres.
> Support authorization via GRANT and REVOKE DDL commands
> ---
>
> Key: CALCITE-5681
> URL: https://issues.apache.org/jira/browse/CALCITE-5681
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
>
> Support authorization via GRANT and REVOKE DDL commands.
> While CALCITE-2194 describes how authorization could be built into the schema
> (e.g. user1 can see tables table1 and table2), it requires people to create
> their own Schema objects. This feature would add GRANT and REVOKE commands to
> the DDL parser in the "server" component.
> The syntax is TBD but would look something like this:
> {code:java}
> GRANT SELECT ON TABLE table1, table2 TO user1;
> REVOKE ALL ON table1 FROM user1; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5681) Support authorization via GRANT and REVOKE DDL commands
[
https://issues.apache.org/jira/browse/CALCITE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738352#comment-17738352
]
hongyu guo commented on CALCITE-5681:
-
[postgres grant sql|https://www.postgresql.org/docs/current/sql-grant.html]
I actually followed the syntax used in Postgres ({{{}ALL TABLES IN SCHEMA{}}}).
And using wildcards like {{}}
{code:java}
grant select on s.* to user{code}
{{}}
is not supported in Postgres.
> Support authorization via GRANT and REVOKE DDL commands
> ---
>
> Key: CALCITE-5681
> URL: https://issues.apache.org/jira/browse/CALCITE-5681
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
>
> Support authorization via GRANT and REVOKE DDL commands.
> While CALCITE-2194 describes how authorization could be built into the schema
> (e.g. user1 can see tables table1 and table2), it requires people to create
> their own Schema objects. This feature would add GRANT and REVOKE commands to
> the DDL parser in the "server" component.
> The syntax is TBD but would look something like this:
> {code:java}
> GRANT SELECT ON TABLE table1, table2 TO user1;
> REVOKE ALL ON table1 FROM user1; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738350#comment-17738350
]
Guillaume Massé edited comment on CALCITE-5809 at 6/29/23 3:18 AM:
---
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL, POSTGRESQL
soundex BIG_QUERY, MYSQL, POSTGRESQL, ORACLE
space MYSQL
split BIG_QUERY
startswith (called starts_with in BIG_QUERY)
std (alias for stddev)
timestamp BIG_QUERY
timestamp_micros BIG_QUERY
timestamp_millis BIG_QUERY
timestamp_seconds BIG_QUERY
to_date POSTGRESQL, ORACLE
to_timestamp POSTGRESQL, ORACLE
translate (called translate3 in BIG_QUERY,
ORACLE, POSTGRESQL)
unix_date BIG_QUERY
unix_micros BIG_QUERY
unix_millis BIG_QUERY
unix_seconds BIG_QUERY {code}
was (Author: masseguillaume):
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL, POSTGRESQL
soundex
[jira] [Comment Edited] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738350#comment-17738350
]
Guillaume Massé edited comment on CALCITE-5809 at 6/29/23 3:18 AM:
---
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL, POSTGRESQL
soundex BIG_QUERY, MYSQL, POSTGRESQL, ORACLE
space MYSQL
split BIG_QUERY
startswith (called starts_with in BIG_QUERY)
std (alias for stddev)
timestamp BIG_QUERY
timestamp_micros BIG_QUERY
timestamp_millis BIG_QUERY
timestamp_seconds BIG_QUERY
to_date POSTGRESQL, ORACLE
to_timestamp POSTGRESQL, ORACLE
translate (called translate3 in BIG_QUERY,
ORACLE, POSTGRESQL)
unix_date BIG_QUERY
unix_micros BIG_QUERY
unix_millis BIG_QUERY
unix_seconds BIG_QUERY {code}
was (Author: masseguillaume):
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL,
[jira] [Comment Edited] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738350#comment-17738350
]
Guillaume Massé edited comment on CALCITE-5809 at 6/29/23 3:18 AM:
---
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL, POSTGRESQL
soundex BIG_QUERY, MYSQL, POSTGRESQL, ORACLE
space MYSQL
split BIG_QUERY
startswith (called starts_with in BIG_QUERY)
std (alias for stddev)
timestamp BIG_QUERY
timestamp_micros BIG_QUERY
timestamp_millis BIG_QUERY
timestamp_seconds BIG_QUERY
to_date POSTGRESQL, ORACLE
to_timestamp POSTGRESQL, ORACLEtranslate
(called translate3 in BIG_QUERY, ORACLE, POSTGRESQL)
unix_date BIG_QUERY
unix_micros BIG_QUERY
unix_millis BIG_QUERY
unix_seconds BIG_QUERY {code}
was (Author: masseguillaume):
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL,
[jira] [Commented] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738350#comment-17738350
]
Guillaume Massé commented on CALCITE-5809:
--
Here is a list of functions that are already available via other library:
{code:java}
base64 (called TO_BASE64)
chr BIG_QUERY, ORACLE, POSTGRESQL
concat_ws MYSQL, POSTGRESQL
convert_timezone POSTGRESQL
date BIG_QUERY
date_add BIG_QUERY
date_diff BIG_QUERY
date_from_unix_date BIG_QUERY
date_part POSTGRESQL
date_sub BIG_QUERY
date_trunc BIG_QUERY
dateadd MSSQL, POSTGRESQL
datediff MSSQL, POSTGRESQL
datepart MSSQL
endswith (called ends_with in BIG_QUERY)
greatest BIG_QUERY, ORACLE
ifnull BIG_QUERY
instr BIG_QUERY, MYSQL, ORACLE
least BIG_QUERY, ORACLE
left BIG_QUERY, MYSQL, POSTGRESQL
log BIG_QUERY
lpad BIG_QUERY, ORACLE
ltrim BIG_QUERY, ORACLE
md5 BIG_QUERY, MYSQL, POSTGRESQL
position (called strpos in BIG_QUERY,
POSTGRESQL)
pow BIG_QUERY
random (alias for rand)
regexp_replace MYSQL, ORACLE
repeat BIG_QUERY, MYSQL, POSTGRESQL
reverse (called array_reverse in BIG_QUERY)
right BIG_QUERY, MYSQL, POSTGRESQL
rpad BIG_QUERY, ORACLE
rtrim BIG_QUERY, ORACLE
sha (alias for sha1)
sha1 BIG_QUERY, MYSQL, POSTGRESQL
soundex BIG_QUERY, MYSQL, POSTGRESQL, ORACLE
space MYSQL
split BIG_QUERY
startswith (called starts_with in BIG_QUERY)std
(alias for stddev)
timestamp BIG_QUERY
timestamp_micros BIG_QUERY
timestamp_millis BIG_QUERY
timestamp_seconds BIG_QUERY
to_date POSTGRESQL, ORACLE
to_timestamp POSTGRESQL, ORACLEtranslate
(called translate3 in BIG_QUERY, ORACLE, POSTGRESQL)
unix_date BIG_QUERY
unix_micros BIG_QUERY
unix_millis BIG_QUERY
unix_seconds BIG_QUERY {code}
> enable to_date and to_timestamp in Apache Spark Library
> ---
>
> Key: CALCITE-5809
> URL: https://issues.apache.org/jira/browse/CALCITE-5809
> Project: Calcite
> Issue Type: Improvement
>Reporter: Guillaume Massé
>Priority: Minor
>
> Those functions are available in Calcite but via different library, we simply
> need to add them to the libraries list.
>
> [https://spark.apache.org/docs/2.3.0/api/sql/#to_date]
> [https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1262-L1267]
>
> https://spark.apache.org/docs/2.3.0/api/sql/#to_timestamp
> https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1271-L1276
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5772) Add MAP_CONCAT, MAP_FROM_ENTRIES for Spark dialect
[
https://issues.apache.org/jira/browse/CALCITE-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738345#comment-17738345
]
Jacky Lau commented on CALCITE-5772:
hi [~julianhyde] sorry to bother you, do you have any input on this pr, the pr
is approved?
if not , i will merge it soon.
> Add MAP_CONCAT, MAP_FROM_ENTRIES for Spark dialect
> ---
>
> Key: CALCITE-5772
> URL: https://issues.apache.org/jira/browse/CALCITE-5772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Jacky Lau
>Assignee: Jacky Lau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> h3.
> [map_concat|https://spark.apache.org/docs/latest/api/sql/index.html#map_concat]
> map_concat(map, ...) - Returns the union of all the given maps
> *Examples:*
>
> {code:java}
> > SELECT map_concat(map(1, 'a', 2, 'b'), map(3, 'c'));
> {1:"a",2:"b",3:"c"} {code}
>
>
> h3.
> [map_from_entries|https://spark.apache.org/docs/latest/api/sql/index.html#map_from_entries]
> map_from_entries(arrayOfEntries) - Returns a map created from the given array
> of entries.
> *Examples:*
>
> {code:java}
> > SELECT map_from_entries(array(struct(1, 'a'), struct(2, 'b')));
> {1:"a",2:"b"} {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CALCITE-5772) Add MAP_CONCAT, MAP_FROM_ENTRIES for Spark dialect
[ https://issues.apache.org/jira/browse/CALCITE-5772 ]
Jacky Lau deleted comment on CALCITE-5772:
was (Author: jackylau):
hi [~julianhyde] do you have time to help review?
> Add MAP_CONCAT, MAP_FROM_ENTRIES for Spark dialect
> ---
>
> Key: CALCITE-5772
> URL: https://issues.apache.org/jira/browse/CALCITE-5772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Jacky Lau
>Assignee: Jacky Lau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> h3.
> [map_concat|https://spark.apache.org/docs/latest/api/sql/index.html#map_concat]
> map_concat(map, ...) - Returns the union of all the given maps
> *Examples:*
>
> {code:java}
> > SELECT map_concat(map(1, 'a', 2, 'b'), map(3, 'c'));
> {1:"a",2:"b",3:"c"} {code}
>
>
> h3.
> [map_from_entries|https://spark.apache.org/docs/latest/api/sql/index.html#map_from_entries]
> map_from_entries(arrayOfEntries) - Returns a map created from the given array
> of entries.
> *Examples:*
>
> {code:java}
> > SELECT map_from_entries(array(struct(1, 'a'), struct(2, 'b')));
> {1:"a",2:"b"} {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-985) Validate MERGE
[ https://issues.apache.org/jira/browse/CALCITE-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajun Xie reassigned CALCITE-985: -- Assignee: Jiajun Xie > Validate MERGE > -- > > Key: CALCITE-985 > URL: https://issues.apache.org/jira/browse/CALCITE-985 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Jiajun Xie >Priority: Major > > Now CALCITE-974 is fixed, we can validate INSERT, UPDATE and DELETE; > sql-to-rel conversion also succeeds, although I'm not sure we can execute. > MERGE does not yet pass validation. > I have added SqlToRelConverterTest.testMerge; we need one or two validator > fixes to make it pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738341#comment-17738341
]
Jiajun Xie commented on CALCITE-5805:
-
Thanks for your information.
It seems that I need to add more unit tests to ensure the completion of this
work(CALCITE-985).
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> For the unit test.
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
> * If we enable `assert`, the error will be *AssertionError.*
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
> {code}
> * If we disable `assert`, the error will be *NullPointerException.*
> {code:java}
> java.lang.NullPointerException: rowType
> at java.util.Objects.requireNonNull(Objects.java:228)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
> at
>
[jira] [Commented] (CALCITE-5715) Prune old nodes after projection merging in ProjectMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738339#comment-17738339
]
Benchao Li commented on CALCITE-5715:
-
[~rubenql] Thanks, the [PR|https://github.com/apache/calcite/pull/3216] is
here, and it's simple (just added two lines). If we could reach an agreement
about the change, I think we could try to get it in for 1.35.0, if not, it
would be ok to remove the fixVersion.
> Prune old nodes after projection merging in ProjectMergeRule
>
>
> Key: CALCITE-5715
> URL: https://issues.apache.org/jira/browse/CALCITE-5715
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Benchao Li
>Priority: Major
> Fix For: 1.35.0
>
>
> We already have many similar usages (prune old nodes when the new one is
> obviously better, e.g. in
> [CalcMergeRule|https://github.com/apache/calcite/blob/c56d5564628de6b3265f960764a6f6fc43935a75/core/src/main/java/org/apache/calcite/rel/rules/CalcMergeRule.java#L85-L90]
> to reduce the search scope, I propose to also add this for
> {{ProjectMergeRule}}. Do you have any concerns about this?
> In {{ProjectMergeRule}}, there is a case that after merging the two
> {{Project}}, we'll find the new Project is trivial and we'll transform to the
> bottomProject's
> input(https://github.com/apache/calcite/blob/c56d5564628de6b3265f960764a6f6fc43935a75/core/src/main/java/org/apache/calcite/rel/rules/ProjectMergeRule.java#L132-L139).
> In this case, both topProject and bottomProject could be pruned?
> The reason I propose to do this optimization for {{ProjectMergeRule}} is that
> I met a problem that two sets will point to each other after projection
> merging, and the planner will run into dead loop. (It's hard to show the
> details, I haven't got a simple reproducible demo yet)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5808) Rel-to-Sql conversion should better support grouping or sorting by references or ordinals
[
https://issues.apache.org/jira/browse/CALCITE-5808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-5808:
Description:
While exploring solutions to CALCITE-5724 I produced [this draft
commit|https://github.com/apache/calcite/commit/d644ecee44ffd7927a62be96329cd5456f545de2]
to explore what the Rel-to-Sql conversion process would look like if it were
heavily biased toward using ordinals in the {{GROUP BY}} and {{ORDER BY}}
clauses. It works for most common queries, but I gave up with basically 2
problems yet to be solved:
# Grouping with {{ROLLUP}}, {{CUBE}}, or {{GROUPING SETS}} does not allow
ordinals (at least [according to this presto
ticket|https://github.com/prestodb/presto/issues/9522]; I didn't double-check
any standards or dialects), so my draft solution would have to distinguish
between these cases and a simple group-by, and only use ordinals in the simple
case.
# Window functions with an {{ORDER BY}} clause also use ordinals in my draft.
It seems likely that ordinals are also disallowed in this context, but I'm not
sure. Looking at the results in
{{RelToSqlConverterTest.testConvertWindowToSql()}}, it certainly looks like the
query is incorrect even if ordinals could hypothetically go in a window's
{{ORDER BY}}.
So, I've decided to stop working on this for now, but wanted to preserve my
draft change and start a discussion on this ticket. Here are some thoughts:
# It seems like we can reach a happy middle ground on sorting by using ordinals
whenever the dialect allows *and* the expression returned by {{field()}} is
anything other than a {{SqlIdentifier}} (i.e. a named column reference).
Existing behavior as of writing is to only use ordinals when the expression is
a {{SqlCall}}, but we should use it for literals as well. That would solve
CALCITE-5724, but still use named references for "simple" collations, which
seems to be the case for all window functions.
# When it comes to grouping, things are more complicated. As of writing,
Calcite tends to group by expressions, but some dialects (e.g. BigQuery) can
get easily confused by this, even when the expression in the {{SELECT}} list
perfectly matches that in the {{GROUP BY}} clause. With our Calcite
integration, we need customized cleanup logic to rewrite the {{GROUP BY}}
clauses in terms of aliases / ordinals in the {{SELECT}} list whenever
possible, as a band-aid for this problem. We want to get rid of this band-aid
and upstream a proper solution, and I thought using ordinals could be it, but
the problems with {{GROUPING SETS}} et al still needs to be solved, and Calcite
seems to have poor support for grouping by ordinals in general (see the changes
I had to make to {{RelToSqlConverter.generateGroupList}} in my draft) which
should be improved.
was:
While exploring solutions to CALCITE-5724 I produced [this draft
commit|https://github.com/apache/calcite/commit/d644ecee44ffd7927a62be96329cd5456f545de2]
to explore what the Rel-to-Sql conversion process would look like if it were
heavily biased toward using ordinals in the {{GROUP BY}} and {{ORDER BY}}
clauses. It works for most common queries, but I gave up with basically 2
problems yet to be solved:
# Grouping with {{ROLLUP}}, {{CUBE}}, or {{GROUPING SETS}} does not allow
ordinals (at least [according to this presto
ticket|https://github.com/prestodb/presto/issues/9522]; I didn't double-check
any standards or dialects), so my draft solution would have to distinguish
between these cases and a simple group-by, and only use ordinals in the simple
case.
# Window functions with an {{ORDER BY}} clause also use ordinals in my draft.
It seems likely that ordinals are also disallowed in this context, but I'm not
sure. Looking at the results in
{{RelToSqlConverterTest.testConvertWindowToSql()}}, it certainly looks like the
query is incorrect even if ordinals can hypothetically go in a window's {{ORDER
BY}}.
So, I've decided to stop working on this for now, but wanted to preserve my
draft change and start a discussion on this ticket. Here are some thoughts:
# It seems like we can reach a happy middle ground on sorting by using ordinals
whenever the dialect allows *and* the expression returned by {{field()}} is
anything other than a {{SqlIdentifier}} (i.e. a named column reference).
Existing behavior as of writing is to only use ordinals when the expression is
a {{SqlCall}}, but we should use it for literals as well. That would solve
CALCITE-5724, but still use named references for "simple" collations, which
seems to be the case for all window functions.
# When it comes to grouping, things are more complicated. As of writing,
Calcite tends to group by expressions, but some dialects (e.g. BigQuery) can
get easily confused by this, even when the expression in the {{SELECT}} list
perfectly matches that in the {{GROUP BY}} clause. With our Calcite
[jira] [Resolved] (CALCITE-5786) QuidemTest and DiffRepository have incremental build issues
[
https://issues.apache.org/jira/browse/CALCITE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5786.
--
Fix Version/s: 1.35.0
Resolution: Fixed
Fixed in
[d4276bcc|https://github.com/apache/calcite/commit/d4276bcc19523285ed9385a52741d15e16315e78];
thanks for the PR, [~adayal]!
> QuidemTest and DiffRepository have incremental build issues
> ---
>
> Key: CALCITE-5786
> URL: https://issues.apache.org/jira/browse/CALCITE-5786
> Project: Calcite
> Issue Type: Improvement
> Components: build, tests
>Reporter: Akshay Dayal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
> Attachments: Screenshot 2023-06-17 at 1.01.29 AM.png, Screenshot
> 2023-06-17 at 6.42.57 PM.png, Screenshot 2023-06-17 at 6.43.20 PM.png
>
>
> QuidemTest and DiffRepository have incremental build issues. The reason is
> that they write output to {{build/resources/test}}.
> The {{test}} tasks treat {{build/resources/test}} as an input, so if there
> are changes made to the directory the {{test}} tasks are considered no longer
> UP-TO-DATE.
> Currently {{QuidemTest}} and {{DiffRepository}}, which are used by tests,
> write to this directory. DiffRepository writes test results to be compared
> with expected results. {{QuidemTest}} creates some sql files which are used
> during testing. This causes issues with incremental build support for the
> {{test}} tasks. I'm attaching screenshots from a build scan to show this.
> Neither of these need to be written to the {{build/resources/test}}
> directory, they can be put somewhere else in the {{build}} directory and
> therefore not cause issues with incremental build support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5793) Use NULLS FIRST / LAST when unparsing in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5793.
--
Fix Version/s: 1.35.0
Resolution: Fixed
Fixed in
[7bb4f419|https://github.com/apache/calcite/commit/7bb4f4191ae9f91619d645bc51d6433eebe4d530];
thanks for the PR, [~wnoble]!
> Use NULLS FIRST / LAST when unparsing in BigQuery
> -
>
> Key: CALCITE-5793
> URL: https://issues.apache.org/jira/browse/CALCITE-5793
> Project: Calcite
> Issue Type: Improvement
>Reporter: Will Noble
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> BigQuery added support for {{NULLS FIRST}} and {{NULLS LAST}} in 2020.
> Calcite should use it instead of emulating null direction. CALCITE-5775 has
> context on how this was discovered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5747) Conflicting FLOOR return type between Calcite and BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738326#comment-17738326
]
Tanner Clary commented on CALCITE-5747:
---
[~julianhyde] Done, thanks for letting me know. I'll make sure to do that in
the future.
> Conflicting FLOOR return type between Calcite and BigQuery
> --
>
> Key: CALCITE-5747
> URL: https://issues.apache.org/jira/browse/CALCITE-5747
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> In Calcite, the {{FLOOR}} function return type is set to
> {{ARG0_OR_EXACT_NO_SCALE}}. This means that if the result is not a decimal
> with scale 0, it falls back to whatever the type of {{ARG0}} is
> ([source|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L628-L633]).
>
> For instance, if the {{FLOOR}} function is called with an argument of type
> {{BIGINT}}, the return type will be {{BIGINT}} because it is not a decimal
> with scale 0, so it falls back to {{ARG0}}.
> The issue lies in the fact that BigQuery has different behavior for inferring
> the return type. This inference is done according to [these
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#floor].
>
> This conflicts with Calcite if the argument provided to the {{FLOOR}}
> function is an {{BIGINT}} , {{BigQuery}} returns an {{DOUBLE}} (FLOAT64 in BQ
> terms) while Calcite would return a {{BIGINT}}.
> A consequence of this problem may be seen in the following query:
> {{SELECT TIMESTAMP_SECONDS(CAST(FLOOR(CAST(3 AS BIGINT)) AS BIGINT)}}
> Calcite simplifies the query to {{SELECT TIMESTAMP_SECONDS(FLOOR(3)}} because
> the return type is already a {{BIGINT}} so the cast is deemed unnecessary.
> (The cast within the floor function is just to ensure the operand is of type
> {{BIGINT}} for illustrative purposes).
> When BigQuery receives this query, it throws an error because the return type
> of FLOOR(3) is a {{DOUBLE}} (FLOAT64 in BigQuery terms) and the
> {{TIMESTAMP_SECONDS}} function is expecting an integer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5747) Conflicting FLOOR return type between Calcite and BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary updated CALCITE-5747:
--
Fix Version/s: 1.35.0
> Conflicting FLOOR return type between Calcite and BigQuery
> --
>
> Key: CALCITE-5747
> URL: https://issues.apache.org/jira/browse/CALCITE-5747
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> In Calcite, the {{FLOOR}} function return type is set to
> {{ARG0_OR_EXACT_NO_SCALE}}. This means that if the result is not a decimal
> with scale 0, it falls back to whatever the type of {{ARG0}} is
> ([source|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L628-L633]).
>
> For instance, if the {{FLOOR}} function is called with an argument of type
> {{BIGINT}}, the return type will be {{BIGINT}} because it is not a decimal
> with scale 0, so it falls back to {{ARG0}}.
> The issue lies in the fact that BigQuery has different behavior for inferring
> the return type. This inference is done according to [these
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#floor].
>
> This conflicts with Calcite if the argument provided to the {{FLOOR}}
> function is an {{BIGINT}} , {{BigQuery}} returns an {{DOUBLE}} (FLOAT64 in BQ
> terms) while Calcite would return a {{BIGINT}}.
> A consequence of this problem may be seen in the following query:
> {{SELECT TIMESTAMP_SECONDS(CAST(FLOOR(CAST(3 AS BIGINT)) AS BIGINT)}}
> Calcite simplifies the query to {{SELECT TIMESTAMP_SECONDS(FLOOR(3)}} because
> the return type is already a {{BIGINT}} so the cast is deemed unnecessary.
> (The cast within the floor function is just to ensure the operand is of type
> {{BIGINT}} for illustrative purposes).
> When BigQuery receives this query, it throws an error because the return type
> of FLOOR(3) is a {{DOUBLE}} (FLOAT64 in BigQuery terms) and the
> {{TIMESTAMP_SECONDS}} function is expecting an integer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5775) Null direction emulation broken for complex expressions on some dialects
[
https://issues.apache.org/jira/browse/CALCITE-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5775:
-
Labels: (was: pull-request-available)
> Null direction emulation broken for complex expressions on some dialects
>
>
> Key: CALCITE-5775
> URL: https://issues.apache.org/jira/browse/CALCITE-5775
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Will Noble
>Priority: Minor
>
> This is a problem in BigQuery, and may be a problem in other dialects as
> well. Consider the following piece of valid BQ SQL:
> {code:sql}
> SELECT REPEAT(first_name, 2),
>COUNT(id)
> FROM looker_test.users
> GROUP BY REPEAT(first_name, 2)
> ORDER BY 1
> {code}
> Now consider a version where the {{ORDER BY}} clause is changed to this:
> {code:sql}
> ORDER BY REPEAT(first_name, 2)
> {code}
> This is logically the same query, because the expression in the {{ORDER}}
> clause is the same as the one in the {{SELECT}} / {{GROUP}} clauses. BigQuery
> is sophisticated enough to match the select to the group expression in both
> queries, but cannot match either with the order expression. It gives this
> error: _ORDER BY clause expression references column first_name which is
> neither grouped nor aggregated_.
> So, when sorting by complex expressions in BQ, Calcite relies on either:
> * No null direction emulation required.
> * sorting by alias or ordinal, which is a problem with current null direction
> emulation because it adds an extra complex sort expression, or
> * having a query that just happens to also have the underlying field in the
> {{GROUP BY}} clause by itself, which seems to actually happen pretty often in
> my testing, but obviously shouldn't be a constraint.
> As I wrote that, I realized this may be easily fixable for BQ since it added
> support for {{NULLS FIRST}} / {{LAST}} in 2020 and it seems Calcite has not
> caught up yet. Consider this rel node:
> {code}
> LogicalSort(sort0=[$0], dir0=[ASC])
> LogicalAggregate(group=[{0}], cent=[COUNT($1)])
> LogicalProject($f0=[CASE(IS NULL($4), 0, 1)], MGR=[$3])
> JdbcTableScan(table=[[JDBC_SCOTT, EMP]])
> {code}
> Calcite would convert it to this in BigQuery due to null direction emulation:
> {code:sql}
> SELECT CASE WHEN HIREDATE IS NULL THEN 0 ELSE 1 END AS `$f0`, COUNT(MGR) AS
> cent
> FROM SCOTT.EMP
> GROUP BY CASE WHEN HIREDATE IS NULL THEN 0 ELSE 1 END
> ORDER BY CASE WHEN HIREDATE IS NULL THEN 0 ELSE 1 END IS NULL, 1
> {code}
> Which of course triggers the problem described above. This may be a problem
> for MSSQL as well since it doesn't support {{NULLS LAST}}. The fix for BQ, at
> least, may be to just support {{NULLS LAST}} and sort by ordinal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5756) Expand ProjectJoinRemoveRule to support inner join removal by using the foreign-unique constraints
[
https://issues.apache.org/jira/browse/CALCITE-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736942#comment-17736942
]
winds edited comment on CALCITE-5756 at 6/28/23 11:17 PM:
--
[~jhyde] Thanks for your check. I aggre with you.
As you said, it is reasonable that foreignKeys returning should include a. what
table each column references b. composite foreign keys.
I have some ideas to make RelMetadataQuery#getForeignKeys to satisfy the above,
I will try to fix it.
was (Author: JIRAUSER292370):
[~jhyde] Thanks for your check. I aggre with you.
As you said, it is reasonable that foreignKeys returning should include a. what
table each column references b. composite foreign keys.
I have some ideas to make RelMetadataQuery#getForeignKeys to satisfy the above
, I will try to fix it.
> Expand ProjectJoinRemoveRule to support inner join removal by using the
> foreign-unique constraints
> --
>
> Key: CALCITE-5756
> URL: https://issues.apache.org/jira/browse/CALCITE-5756
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: winds
>Assignee: winds
>Priority: Major
> Labels: pull-request-available
>
> Join elimination is a useful optmize improvement.
> Consider a query that joins the two tables but does not make use of the Dept
> columns:
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp, Dept
> WHERE Emp.deptno = Dept.dno {code}
> Assuming Emp.deptno is the foreign-key and is non-null, Dept.dno is the
> unique-key. The sql above can be rewritten as following. remove the Dept
> table without affecting the resultset.
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp {code}
> Without redundant join elimination, this query execution may perform poorly.
> The optimize improvement is also available in SQL Server, Oracle and
> Snowflake and so on.
> In Calcite, i think that is also useful. The infrastructure that join
> elimination depend on is already available.
> The main steps are as follows:
> 1. Analyse the column used by project, and then split them to left and right
> side.
> 2. Acccording to the project info above and outer join type, bail out in some
> scene.
> 3. Get join info such as join keys.
> 4. For inner join check foreign and unique keys, these may use
> RelMetadataQuery#getForeignKeys(newly add, similar to
> RelMetadataQuery#getUniqueKeys),
> RelOptTable#getReferentialConstraints.
> 5. Check removing side join keys are areColumnsUnique both for outer join and
> inner join.
> 6. If all done, calculate the fianl project and transform.
> Please help me to check the improvement whether is useful or not.
> And i would like to add this improvement to Calcite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5756) Expand ProjectJoinRemoveRule to support inner join removal by using the foreign-unique constraints
[
https://issues.apache.org/jira/browse/CALCITE-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736942#comment-17736942
]
winds edited comment on CALCITE-5756 at 6/28/23 11:17 PM:
--
[~jhyde] Thanks for your check. I aggre with you.
As you said, it is reasonable that foreignKeys returning should include a. what
table each column references b. composite foreign keys.
I have some ideas to make RelMetadataQuery#getForeignKeys to satisfy the above
, I will try to fix it.
was (Author: JIRAUSER292370):
Thanks for your check. Get your point, my understanding is as follows:
Firstly.
For the following sql, assumption there are constraints that Emp.deptno foreign
key reference Dept.deptno unique key,
Emp.ename foreign key reference Dept.deptno unique key.
{code:java}
SELECT e.ename, e.deptno, DEPT.name
FROM
(SELECT Emp.ename, Emp.deptno FROM Emp) e
INNER JOIN
Dept
ON e.deptno on Dept.deptno{code}
It seems that There are two ways to get constraints on current rel node.
a.
RelMetadataQuery#getForeignKeys mark out which position is the valid foreign
key(if the position is on aggregate function, it seems invalid),
if we want to know which unqinue key the foreign key reference, we can get the
relation by RelMetadataQuery#getColumnOrigin,such as the logic in method
[ProjectJoinRemoveRule#areForeignKeysValid()|https://github.com/JingDas/calcite/blob/586dbf40d6ef7752b554c08fe573e600da456876/core/src/main/java/org/apache/calcite/rel/rules/ProjectJoinRemoveRule.java#L170].
b.
If we want to get all constraint information from
RelMetadataQuery#getForeignKeys, it seems that
RelMetadataQuery#getForeignKeys should return Set>, which represent that
foreign key positions reference unique key positions correspondingly on current
relNode.
As above sql and logic, if we call the method
RelMetadataQuery#getForeignKeys(Project(Emp.ename, Emp.deptno), true),
it seems return [<[Emp.ename, Emp.deptno], null>], because it reference another
table Dept, but the Dept does not appear
in the current project relnode.
To be precise, I have no more ideas for that how to keep track and record this
constraint relationship
during the bottom-up transfer derivation process of rel node. So I took the
first approach above.
Secondly.
I just searched some docs. And find that in some database such as Mysql,
SqlServer and so on, Foreign Key are allowed to be
composited.For the method RelMetadataQuery#getForeignKeys, it seems to return
Set which can represent the information
for composite foreign keys, I will use Set to fix the
composite foreign keys representation.
WDYT?
> Expand ProjectJoinRemoveRule to support inner join removal by using the
> foreign-unique constraints
> --
>
> Key: CALCITE-5756
> URL: https://issues.apache.org/jira/browse/CALCITE-5756
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: winds
>Assignee: winds
>Priority: Major
> Labels: pull-request-available
>
> Join elimination is a useful optmize improvement.
> Consider a query that joins the two tables but does not make use of the Dept
> columns:
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp, Dept
> WHERE Emp.deptno = Dept.dno {code}
> Assuming Emp.deptno is the foreign-key and is non-null, Dept.dno is the
> unique-key. The sql above can be rewritten as following. remove the Dept
> table without affecting the resultset.
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp {code}
> Without redundant join elimination, this query execution may perform poorly.
> The optimize improvement is also available in SQL Server, Oracle and
> Snowflake and so on.
> In Calcite, i think that is also useful. The infrastructure that join
> elimination depend on is already available.
> The main steps are as follows:
> 1. Analyse the column used by project, and then split them to left and right
> side.
> 2. Acccording to the project info above and outer join type, bail out in some
> scene.
> 3. Get join info such as join keys.
> 4. For inner join check foreign and unique keys, these may use
> RelMetadataQuery#getForeignKeys(newly add, similar to
> RelMetadataQuery#getUniqueKeys),
> RelOptTable#getReferentialConstraints.
> 5. Check removing side join keys are areColumnsUnique both for outer join and
> inner join.
> 6. If all done, calculate the fianl project and transform.
> Please help me to check the improvement whether is useful or not.
> And i would like to add this improvement to Calcite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5747) Conflicting FLOOR return type between Calcite and BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738325#comment-17738325
]
Julian Hyde commented on CALCITE-5747:
--
[~tanclary], Can you also set fixVersion to 1.35.0?
(The protocol is: set status = resolved, resolution = fixed, fixVersion to the
upcoming release, add a comment. The release manager will change the status to
closed after the release.)
> Conflicting FLOOR return type between Calcite and BigQuery
> --
>
> Key: CALCITE-5747
> URL: https://issues.apache.org/jira/browse/CALCITE-5747
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> In Calcite, the {{FLOOR}} function return type is set to
> {{ARG0_OR_EXACT_NO_SCALE}}. This means that if the result is not a decimal
> with scale 0, it falls back to whatever the type of {{ARG0}} is
> ([source|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L628-L633]).
>
> For instance, if the {{FLOOR}} function is called with an argument of type
> {{BIGINT}}, the return type will be {{BIGINT}} because it is not a decimal
> with scale 0, so it falls back to {{ARG0}}.
> The issue lies in the fact that BigQuery has different behavior for inferring
> the return type. This inference is done according to [these
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#floor].
>
> This conflicts with Calcite if the argument provided to the {{FLOOR}}
> function is an {{BIGINT}} , {{BigQuery}} returns an {{DOUBLE}} (FLOAT64 in BQ
> terms) while Calcite would return a {{BIGINT}}.
> A consequence of this problem may be seen in the following query:
> {{SELECT TIMESTAMP_SECONDS(CAST(FLOOR(CAST(3 AS BIGINT)) AS BIGINT)}}
> Calcite simplifies the query to {{SELECT TIMESTAMP_SECONDS(FLOOR(3)}} because
> the return type is already a {{BIGINT}} so the cast is deemed unnecessary.
> (The cast within the floor function is just to ensure the operand is of type
> {{BIGINT}} for illustrative purposes).
> When BigQuery receives this query, it throws an error because the return type
> of FLOOR(3) is a {{DOUBLE}} (FLOAT64 in BigQuery terms) and the
> {{TIMESTAMP_SECONDS}} function is expecting an integer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
[ https://issues.apache.org/jira/browse/CALCITE-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738324#comment-17738324 ] Guillaume Massé commented on CALCITE-5809: -- It looks like there is more: split [https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L314-L325] [https://spark.apache.org/docs/2.3.0/api/sql/#split] I will compile a list of functions we simply need to enable. > enable to_date and to_timestamp in Apache Spark Library > --- > > Key: CALCITE-5809 > URL: https://issues.apache.org/jira/browse/CALCITE-5809 > Project: Calcite > Issue Type: Improvement >Reporter: Guillaume Massé >Priority: Minor > > Those functions are available in Calcite but via different library, we simply > need to add them to the libraries list. > > [https://spark.apache.org/docs/2.3.0/api/sql/#to_date] > [https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1262-L1267] > > https://spark.apache.org/docs/2.3.0/api/sql/#to_timestamp > https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1271-L1276 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5809) enable to_date and to_timestamp in Apache Spark Library
Guillaume Massé created CALCITE-5809: Summary: enable to_date and to_timestamp in Apache Spark Library Key: CALCITE-5809 URL: https://issues.apache.org/jira/browse/CALCITE-5809 Project: Calcite Issue Type: Improvement Reporter: Guillaume Massé Those functions are available in Calcite but via different library, we simply need to add them to the libraries list. [https://spark.apache.org/docs/2.3.0/api/sql/#to_date] [https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1262-L1267] https://spark.apache.org/docs/2.3.0/api/sql/#to_timestamp https://github.com/apache/calcite/blob/50f0e185896a4afb7c77bb6fb4efe41c1531dcfe/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L1271-L1276 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5808) Rel-to-Sql conversion should better support grouping or sorting by references or ordinals
[
https://issues.apache.org/jira/browse/CALCITE-5808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-5808:
Description:
While exploring solutions to CALCITE-5724 I produced [this draft
commit|https://github.com/apache/calcite/commit/d644ecee44ffd7927a62be96329cd5456f545de2]
to explore what the Rel-to-Sql conversion process would look like if it were
heavily biased toward using ordinals in the {{GROUP BY}} and {{ORDER BY}}
clauses. It works for most common queries, but I gave up with basically 2
problems yet to be solved:
# Grouping with {{ROLLUP}}, {{CUBE}}, or {{GROUPING SETS}} does not allow
ordinals (at least [according to this presto
ticket|https://github.com/prestodb/presto/issues/9522]; I didn't double-check
any standards or dialects), so my draft solution would have to distinguish
between these cases and a simple group-by, and only use ordinals in the simple
case.
# Window functions with an {{ORDER BY}} clause also use ordinals in my draft.
It seems likely that ordinals are also disallowed in this context, but I'm not
sure. Looking at the results in
{{RelToSqlConverterTest.testConvertWindowToSql()}}, it certainly looks like the
query is incorrect even if ordinals can hypothetically go in a window's {{ORDER
BY}}.
So, I've decided to stop working on this for now, but wanted to preserve my
draft change and start a discussion on this ticket. Here are some thoughts:
# It seems like we can reach a happy middle ground on sorting by using ordinals
whenever the dialect allows *and* the expression returned by {{field()}} is
anything other than a {{SqlIdentifier}} (i.e. a named column reference).
Existing behavior as of writing is to only use ordinals when the expression is
a {{SqlCall}}, but we should use it for literals as well. That would solve
CALCITE-5724, but still use named references for "simple" collations, which
seems to be the case for all window functions.
# When it comes to grouping, things are more complicated. As of writing,
Calcite tends to group by expressions, but some dialects (e.g. BigQuery) can
get easily confused by this, even when the expression in the {{SELECT}} list
perfectly matches that in the {{GROUP BY}} clause. With our Calcite
integration, we need customized cleanup logic to rewrite the {{GROUP BY}}
clauses in terms of aliases / ordinals in the {{SELECT}} list whenever
possible, as a band-aid for this problem. We want to get rid of this band-aid
and upstream a proper solution, and I thought using ordinals could be it, but
the problems with {{GROUPING SETS}} et al still needs to be solved, and Calcite
seems to have poor support for grouping by ordinals in general (see the changes
I had to make to {{RelToSqlConverter.generateGroupList}} in my draft) which
should be improved.
was:
While exploring solutions to CALCITE-5724 I produced [this draft
PR|https://github.com/apache/calcite/commit/d644ecee44ffd7927a62be96329cd5456f545de2]
to explore what the Rel-to-Sql conversion process would look like if it were
heavily biased toward using ordinals in the {{GROUP BY}} and {{ORDER BY}}
clauses. It works for most common queries, but I gave up with basically 2
problems yet to be solved:
# Grouping with {{ROLLUP}}, {{CUBE}}, or {{GROUPING SETS}} does not allow
ordinals (at least [according to this presto
ticket|https://github.com/prestodb/presto/issues/9522]; I didn't double-check
any standards or dialects), so my draft solution would have to distinguish
between these cases and a simple group-by, and only use ordinals in the simple
case.
# Window functions with an {{ORDER BY}} clause also use ordinals in my draft.
It seems likely that ordinals are also disallowed in this context, but I'm not
sure. Looking at the results in
{{RelToSqlConverterTest.testConvertWindowToSql()}}, it certainly looks like the
query is incorrect even if ordinals can hypothetically go in a window's {{ORDER
BY}}.
So, I've decided to stop working on this for now, but wanted to preserve my
draft change and start a discussion on this ticket. Here are some thoughts:
# It seems like we can reach a happy middle ground on sorting by using ordinals
whenever the dialect allows *and* the expression returned by {{field()}} is
anything other than a {{SqlIdentifier}} (i.e. a named column reference).
Existing behavior as of writing is to only use ordinals when the expression is
a {{SqlCall}}, but we should use it for literals as well. That would solve
CALCITE-5724, but still use named references for "simple" collations, which
seems to be the case for all window functions.
# When it comes to grouping, things are more complicated. As of writing,
Calcite tends to group by expressions, but some dialects (e.g. BigQuery) can
get easily confused by this, even when the expression in the {{SELECT}} list
perfectly matches that in the {{GROUP BY}} clause. With our Calcite
integration,
[jira] [Created] (CALCITE-5808) Rel-to-Sql conversion should better support grouping or sorting by references or ordinals
Will Noble created CALCITE-5808:
---
Summary: Rel-to-Sql conversion should better support grouping or
sorting by references or ordinals
Key: CALCITE-5808
URL: https://issues.apache.org/jira/browse/CALCITE-5808
Project: Calcite
Issue Type: Improvement
Reporter: Will Noble
While exploring solutions to CALCITE-5724 I produced [this draft
PR|https://github.com/apache/calcite/commit/d644ecee44ffd7927a62be96329cd5456f545de2]
to explore what the Rel-to-Sql conversion process would look like if it were
heavily biased toward using ordinals in the {{GROUP BY}} and {{ORDER BY}}
clauses. It works for most common queries, but I gave up with basically 2
problems yet to be solved:
# Grouping with {{ROLLUP}}, {{CUBE}}, or {{GROUPING SETS}} does not allow
ordinals (at least [according to this presto
ticket|https://github.com/prestodb/presto/issues/9522]; I didn't double-check
any standards or dialects), so my draft solution would have to distinguish
between these cases and a simple group-by, and only use ordinals in the simple
case.
# Window functions with an {{ORDER BY}} clause also use ordinals in my draft.
It seems likely that ordinals are also disallowed in this context, but I'm not
sure. Looking at the results in
{{RelToSqlConverterTest.testConvertWindowToSql()}}, it certainly looks like the
query is incorrect even if ordinals can hypothetically go in a window's {{ORDER
BY}}.
So, I've decided to stop working on this for now, but wanted to preserve my
draft change and start a discussion on this ticket. Here are some thoughts:
# It seems like we can reach a happy middle ground on sorting by using ordinals
whenever the dialect allows *and* the expression returned by {{field()}} is
anything other than a {{SqlIdentifier}} (i.e. a named column reference).
Existing behavior as of writing is to only use ordinals when the expression is
a {{SqlCall}}, but we should use it for literals as well. That would solve
CALCITE-5724, but still use named references for "simple" collations, which
seems to be the case for all window functions.
# When it comes to grouping, things are more complicated. As of writing,
Calcite tends to group by expressions, but some dialects (e.g. BigQuery) can
get easily confused by this, even when the expression in the {{SELECT}} list
perfectly matches that in the {{GROUP BY}} clause. With our Calcite
integration, we need customized cleanup logic to rewrite the {{GROUP BY}}
clauses in terms of aliases / ordinals in the {{SELECT}} list whenever
possible, as a band-aid for this problem. We want to get rid of this band-aid
and upstream a proper solution, and I thought using ordinals could be it, but
the problems with {{GROUPING SETS}} et al still needs to be solved, and Calcite
seems to have poor support for grouping by ordinals in general (see the changes
I had to make to {{RelToSqlConverter.generateGroupList}} in my draft) which
should be improved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5807) implement substring_index in Apache Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738320#comment-17738320
]
Tanner Clary commented on CALCITE-5807:
---
I'm not positive but I would imagine some of the existing
{{SUBSTRING}}/{{SPLIT}}/{{INSTR}} implementations could maybe be useful for
this, feel free to tag me as a reviewer if you would like
> implement substring_index in Apache Spark Library
> -
>
> Key: CALCITE-5807
> URL: https://issues.apache.org/jira/browse/CALCITE-5807
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Guillaume Massé
>Priority: Minor
>
> [https://spark.apache.org/docs/2.3.0/api/sql/#substring_index]
>
>
> {code:java}
> substring_index(str, delim, count) - Returns the substring from str before
> count occurrences of the delimiter delim. If count is positive, everything to
> the left of the final delimiter (counting from the left) is returned. If
> count is negative, everything to the right of the final delimiter (counting
> from the right) is returned. The function substring_index performs a
> case-sensitive match when searching for delim.
> Examples:
>
> > SELECT substring_index('www.apache.org', '.', 2); www.apache
> {code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5807) implement substring_index in Apache Spark Library
Guillaume Massé created CALCITE-5807:
Summary: implement substring_index in Apache Spark Library
Key: CALCITE-5807
URL: https://issues.apache.org/jira/browse/CALCITE-5807
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Guillaume Massé
[https://spark.apache.org/docs/2.3.0/api/sql/#substring_index]
{code:java}
substring_index(str, delim, count) - Returns the substring from str before
count occurrences of the delimiter delim. If count is positive, everything to
the left of the final delimiter (counting from the left) is returned. If count
is negative, everything to the right of the final delimiter (counting from the
right) is returned. The function substring_index performs a case-sensitive
match when searching for delim.
Examples:
> SELECT substring_index('www.apache.org', '.', 2); www.apache
{code}
{{}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5806) add a String data type
Guillaume Massé created CALCITE-5806:
Summary: add a String data type
Key: CALCITE-5806
URL: https://issues.apache.org/jira/browse/CALCITE-5806
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.34.0
Reporter: Guillaume Massé
Apache Spark as a String data type:
[https://spark.apache.org/docs/latest/sql-ref-datatypes.html]
{code:java}
spark.sql("select concat(cast(1 as string), 'b') as out").show
+---+
|out|
+---+
| 1b|
+---+ {code}
I would like to be able to parse & validate this query.
https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types#string_type
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5731) cast to row type should throw exception when contains null/not null constraint
[
https://issues.apache.org/jira/browse/CALCITE-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5731:
---
Fix Version/s: (was: 1.35.0)
> cast to row type should throw exception when contains null/not null constraint
> --
>
> Key: CALCITE-5731
> URL: https://issues.apache.org/jira/browse/CALCITE-5731
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Jacky Lau
>Assignee: Jacky Lau
>Priority: Major
> Labels: pull-request-available
>
> the cast standard grammar it here from iso 2016
> {code:java}
> // code placeholder
> ::=
> CAST AS
> ::=
>
> |
> ::=
>
> |
> ::=
>
> |
> |
> |
> |
> ::=
>
> |
> ::=
> ARRAY
> [trigraph> ] {code}
>
> not null/ null are constraint, can not be in cast, only can be in ddl
> {code:java}
> // this simple type and collection type will throw exception in calcite now
> expr("cast(x as integer ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer ^not^ null array)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer array ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> // but the followings are not
> expr("cast(x as row(f0 int ^not^ null))")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as row(f0 varchar ^null^))")
> .fails("(?s).*Encountered \"null\" at .*");
> expr("cast(x as row(f0 int ^not^ null, f1 varchar ^null^))")
> .fails("(?s).*Encountered \"not\" at .*");{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5731) cast to row type should throw exception when contains null/not null constraint
[
https://issues.apache.org/jira/browse/CALCITE-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738290#comment-17738290
]
Ruben Q L commented on CALCITE-5731:
[~jackylau] I'm removing the "fixVersion=1.35" from this one. It seems we need
further clarifications about this issue, and we are approaching the 1.35 RC.
> cast to row type should throw exception when contains null/not null constraint
> --
>
> Key: CALCITE-5731
> URL: https://issues.apache.org/jira/browse/CALCITE-5731
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Jacky Lau
>Assignee: Jacky Lau
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> the cast standard grammar it here from iso 2016
> {code:java}
> // code placeholder
> ::=
> CAST AS
> ::=
>
> |
> ::=
>
> |
> ::=
>
> |
> |
> |
> |
> ::=
>
> |
> ::=
> ARRAY
> [trigraph> ] {code}
>
> not null/ null are constraint, can not be in cast, only can be in ddl
> {code:java}
> // this simple type and collection type will throw exception in calcite now
> expr("cast(x as integer ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer ^not^ null array)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer array ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> // but the followings are not
> expr("cast(x as row(f0 int ^not^ null))")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as row(f0 varchar ^null^))")
> .fails("(?s).*Encountered \"null\" at .*");
> expr("cast(x as row(f0 int ^not^ null, f1 varchar ^null^))")
> .fails("(?s).*Encountered \"not\" at .*");{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5731) Cast to row type should throw exception when contains null/not null constraint
[
https://issues.apache.org/jira/browse/CALCITE-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5731:
---
Summary: Cast to row type should throw exception when contains null/not
null constraint (was: cast to row type should throw exception when contains
null/not null constraint)
> Cast to row type should throw exception when contains null/not null constraint
> --
>
> Key: CALCITE-5731
> URL: https://issues.apache.org/jira/browse/CALCITE-5731
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Jacky Lau
>Assignee: Jacky Lau
>Priority: Major
> Labels: pull-request-available
>
> the cast standard grammar it here from iso 2016
> {code:java}
> // code placeholder
> ::=
> CAST AS
> ::=
>
> |
> ::=
>
> |
> ::=
>
> |
> |
> |
> |
> ::=
>
> |
> ::=
> ARRAY
> [trigraph> ] {code}
>
> not null/ null are constraint, can not be in cast, only can be in ddl
> {code:java}
> // this simple type and collection type will throw exception in calcite now
> expr("cast(x as integer ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer ^not^ null array)")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as integer array ^not^ null)")
> .fails("(?s).*Encountered \"not\" at .*");
> // but the followings are not
> expr("cast(x as row(f0 int ^not^ null))")
> .fails("(?s).*Encountered \"not\" at .*");
> expr("cast(x as row(f0 varchar ^null^))")
> .fails("(?s).*Encountered \"null\" at .*");
> expr("cast(x as row(f0 int ^not^ null, f1 varchar ^null^))")
> .fails("(?s).*Encountered \"not\" at .*");{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5715) Prune old nodes after projection merging in ProjectMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738289#comment-17738289
]
Ruben Q L commented on CALCITE-5715:
[~libenchao] what's the status on this one? Given the proximity of 1.35 RC,
shall we remove the "fixVersion=1.35" from here?
> Prune old nodes after projection merging in ProjectMergeRule
>
>
> Key: CALCITE-5715
> URL: https://issues.apache.org/jira/browse/CALCITE-5715
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Benchao Li
>Priority: Major
> Fix For: 1.35.0
>
>
> We already have many similar usages (prune old nodes when the new one is
> obviously better, e.g. in
> [CalcMergeRule|https://github.com/apache/calcite/blob/c56d5564628de6b3265f960764a6f6fc43935a75/core/src/main/java/org/apache/calcite/rel/rules/CalcMergeRule.java#L85-L90]
> to reduce the search scope, I propose to also add this for
> {{ProjectMergeRule}}. Do you have any concerns about this?
> In {{ProjectMergeRule}}, there is a case that after merging the two
> {{Project}}, we'll find the new Project is trivial and we'll transform to the
> bottomProject's
> input(https://github.com/apache/calcite/blob/c56d5564628de6b3265f960764a6f6fc43935a75/core/src/main/java/org/apache/calcite/rel/rules/ProjectMergeRule.java#L132-L139).
> In this case, both topProject and bottomProject could be pruned?
> The reason I propose to do this optimization for {{ProjectMergeRule}} is that
> I met a problem that two sets will point to each other after projection
> merging, and the planner will run into dead loop. (It's hard to show the
> details, I haven't got a simple reproducible demo yet)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5539) GREATEST/LEAST/COALESCE OperandTypes is not correct, which should use AT_LEAST_ONE_SAME_VARIADIC like array_concat
[ https://issues.apache.org/jira/browse/CALCITE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738288#comment-17738288 ] Ruben Q L commented on CALCITE-5539: [~jackylau] if I understand correctly, the problem is that GREATEST/LEAST/COALESCE can be called without parameters? Could you please provide a unit test showing the issue? In any case, since this does not seem a regression, we have no PR for this and we are on the verge of producing 1.35 RC, I'm removing the fixVersion=1.35; we can continue the discussion for the next release. > GREATEST/LEAST/COALESCE OperandTypes is not correct, which should use > AT_LEAST_ONE_SAME_VARIADIC like array_concat > -- > > Key: CALCITE-5539 > URL: https://issues.apache.org/jira/browse/CALCITE-5539 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Jacky Lau >Priority: Major > Fix For: 1.35.0 > > Attachments: image-2023-02-22-18-59-50-951.png, > image-2023-02-22-19-24-46-574.png > > > i found it is not correct. and SAME_VARIADIC is developped in 2014, which > may not fixed. > > !image-2023-02-22-18-59-50-951.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5539) GREATEST/LEAST/COALESCE OperandTypes is not correct, which should use AT_LEAST_ONE_SAME_VARIADIC like array_concat
[ https://issues.apache.org/jira/browse/CALCITE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L updated CALCITE-5539: --- Fix Version/s: (was: 1.35.0) > GREATEST/LEAST/COALESCE OperandTypes is not correct, which should use > AT_LEAST_ONE_SAME_VARIADIC like array_concat > -- > > Key: CALCITE-5539 > URL: https://issues.apache.org/jira/browse/CALCITE-5539 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Jacky Lau >Priority: Major > Attachments: image-2023-02-22-18-59-50-951.png, > image-2023-02-22-19-24-46-574.png > > > i found it is not correct. and SAME_VARIADIC is developped in 2014, which > may not fixed. > > !image-2023-02-22-18-59-50-951.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5732) EnumerableHashJoin and EnumerableMergeJoin on composite key return rows matching condition 'null = null'
[
https://issues.apache.org/jira/browse/CALCITE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5732:
---
Fix Version/s: (was: 1.35.0)
> EnumerableHashJoin and EnumerableMergeJoin on composite key return rows
> matching condition 'null = null'
>
>
> Key: CALCITE-5732
> URL: https://issues.apache.org/jira/browse/CALCITE-5732
> Project: Calcite
> Issue Type: Bug
> Components: linq4j
>Reporter: Viggo Chen
>Priority: Major
>
> In `EnumerableJoinTest#testMergeJoinWithCompositeKeyAndNullValues`, the query
> is like
> {code:java}
> select
> emps.empid
> from
> emps a join emps b
> on a.deptno = b.deptno
> and a.commission = b.commission;{code}
> and the data is like
> {code:java}
> INSERT INTO "emps" VALUES (100, 10, 'Bill', 1, 1000);
> INSERT INTO "emps" VALUES (200, 20, 'Eric', 8000, 500);
> INSERT INTO "emps" VALUES (150, 10, 'Sebastian', 7000, null);
> INSERT INTO "emps" VALUES (110, 10, 'Theodore', 11500, 250); {code}
> And row with empid = 150 is in expected result. Is this the expected result
> of join with null condition.
> Whats more hash join result with condition a.deptno = b.deptno and
> a.commission = b.commission is same as merge join. And if there is just one
> condition a.commission = b.commission, the result do not include empid = 150.
>
> Here is a unit test for it
> {code:java}
> @Test void testHashJoinWithCompositeKeyAndNullValues() {
> // Both join side 'commission' a limited to null, so a.commission =
> b.commission should always be false.
> // So all columns in right table b are expected to be null, this sql should
> result in 0 rows.
> final String sql = "select * from\n"
> + " (select empid, salary, commission from emps where commission is
> null) as a\n"
> + " left join\n"
> + " (select empid, salary, commission from emps where commission is
> null) as b\n"
> + " on a.salary = b.salary and a.commission = b.commission\n"
> + " where b.empid is not null";
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchemaBig()))
> .query(sql)
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_JOIN_RULE);
> planner.addRule(EnumerableRules.ENUMERABLE_MERGE_JOIN_RULE);
> })
> .explainContains("EnumerableHashJoin")
> .returnsCount(0)
> ;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5686) Generalize return types of the linq4j expression shuttle
[
https://issues.apache.org/jira/browse/CALCITE-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738282#comment-17738282
]
Ruben Q L commented on CALCITE-5686:
Thanks [~julianhyde] for checking this. I know that [~thomas.rebele] is on
vacation these days, so probably we will not have a PR soon. In any case, I'm
aware that this is not a high priority for him any more, so I'm reducing the
priority of the ticket (anyway, I agree that it would be nice to have it for
1.36).
> Generalize return types of the linq4j expression shuttle
>
>
> Key: CALCITE-5686
> URL: https://issues.apache.org/jira/browse/CALCITE-5686
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
>
> The following block in org.apache.calcite.linq4j.tree.Shuttle prevents
> replacing constants with other expressions:
> {code:java}
> public ConstantExpression visit(ConstantExpression constantExpression) {
> return constantExpression;
> } {code}
> The return type of the corresponding accept function is more general:
> {code:java}
> @Override public Expression accept(Shuttle shuttle) {
> return shuttle.visit(this);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5686) Generalize return types of the linq4j expression shuttle
[
https://issues.apache.org/jira/browse/CALCITE-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5686:
---
Priority: Minor (was: Major)
> Generalize return types of the linq4j expression shuttle
>
>
> Key: CALCITE-5686
> URL: https://issues.apache.org/jira/browse/CALCITE-5686
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Minor
>
> The following block in org.apache.calcite.linq4j.tree.Shuttle prevents
> replacing constants with other expressions:
> {code:java}
> public ConstantExpression visit(ConstantExpression constantExpression) {
> return constantExpression;
> } {code}
> The return type of the corresponding accept function is more general:
> {code:java}
> @Override public Expression accept(Shuttle shuttle) {
> return shuttle.visit(this);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5732) EnumerableHashJoin and EnumerableMergeJoin on composite key return rows matching condition 'null = null'
[
https://issues.apache.org/jira/browse/CALCITE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738285#comment-17738285
]
Ruben Q L commented on CALCITE-5732:
[~viggoc] since this is not a regression (it seems indeed an old bug), there is
no PR proposed to fix it, and we are preparing the release process of 1.35, I'm
removing the "fixVersion=1.35" of the ticket. But this is definitely a true
problem that we need to take care of.
> EnumerableHashJoin and EnumerableMergeJoin on composite key return rows
> matching condition 'null = null'
>
>
> Key: CALCITE-5732
> URL: https://issues.apache.org/jira/browse/CALCITE-5732
> Project: Calcite
> Issue Type: Bug
> Components: linq4j
>Reporter: Viggo Chen
>Priority: Major
> Fix For: 1.35.0
>
>
> In `EnumerableJoinTest#testMergeJoinWithCompositeKeyAndNullValues`, the query
> is like
> {code:java}
> select
> emps.empid
> from
> emps a join emps b
> on a.deptno = b.deptno
> and a.commission = b.commission;{code}
> and the data is like
> {code:java}
> INSERT INTO "emps" VALUES (100, 10, 'Bill', 1, 1000);
> INSERT INTO "emps" VALUES (200, 20, 'Eric', 8000, 500);
> INSERT INTO "emps" VALUES (150, 10, 'Sebastian', 7000, null);
> INSERT INTO "emps" VALUES (110, 10, 'Theodore', 11500, 250); {code}
> And row with empid = 150 is in expected result. Is this the expected result
> of join with null condition.
> Whats more hash join result with condition a.deptno = b.deptno and
> a.commission = b.commission is same as merge join. And if there is just one
> condition a.commission = b.commission, the result do not include empid = 150.
>
> Here is a unit test for it
> {code:java}
> @Test void testHashJoinWithCompositeKeyAndNullValues() {
> // Both join side 'commission' a limited to null, so a.commission =
> b.commission should always be false.
> // So all columns in right table b are expected to be null, this sql should
> result in 0 rows.
> final String sql = "select * from\n"
> + " (select empid, salary, commission from emps where commission is
> null) as a\n"
> + " left join\n"
> + " (select empid, salary, commission from emps where commission is
> null) as b\n"
> + " on a.salary = b.salary and a.commission = b.commission\n"
> + " where b.empid is not null";
> CalciteAssert.that()
> .with(CalciteConnectionProperty.LEX, Lex.JAVA)
> .with(CalciteConnectionProperty.FORCE_DECORRELATE, false)
> .withSchema("s", new ReflectiveSchema(new HrSchemaBig()))
> .query(sql)
> .withHook(Hook.PLANNER, (Consumer) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_JOIN_RULE);
> planner.addRule(EnumerableRules.ENUMERABLE_MERGE_JOIN_RULE);
> })
> .explainContains("EnumerableHashJoin")
> .returnsCount(0)
> ;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5686) Generalize return types of the linq4j expression shuttle
[
https://issues.apache.org/jira/browse/CALCITE-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738278#comment-17738278
]
Julian Hyde commented on CALCITE-5686:
--
I removed 'fixVersion = 1.35' because there is no PR. However, I agree that the
proposed changes would be useful.
[~thomas.rebele], If you provide a PR shortly I will try to get it merged in
before 1.35.
> Generalize return types of the linq4j expression shuttle
>
>
> Key: CALCITE-5686
> URL: https://issues.apache.org/jira/browse/CALCITE-5686
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
>
> The following block in org.apache.calcite.linq4j.tree.Shuttle prevents
> replacing constants with other expressions:
> {code:java}
> public ConstantExpression visit(ConstantExpression constantExpression) {
> return constantExpression;
> } {code}
> The return type of the corresponding accept function is more general:
> {code:java}
> @Override public Expression accept(Shuttle shuttle) {
> return shuttle.visit(this);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5686) Generalize return types of the linq4j expression shuttle
[
https://issues.apache.org/jira/browse/CALCITE-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738278#comment-17738278
]
Julian Hyde edited comment on CALCITE-5686 at 6/28/23 8:03 PM:
---
I removed 'fixVersion = 1.35' because there is no PR. However, I agree that the
proposed changes would be useful.
[~thomas.rebele], If you provide a PR shortly, and ping me in these comments, I
will try to get it merged in before 1.35.
was (Author: julianhyde):
I removed 'fixVersion = 1.35' because there is no PR. However, I agree that the
proposed changes would be useful.
[~thomas.rebele], If you provide a PR shortly I will try to get it merged in
before 1.35.
> Generalize return types of the linq4j expression shuttle
>
>
> Key: CALCITE-5686
> URL: https://issues.apache.org/jira/browse/CALCITE-5686
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
>
> The following block in org.apache.calcite.linq4j.tree.Shuttle prevents
> replacing constants with other expressions:
> {code:java}
> public ConstantExpression visit(ConstantExpression constantExpression) {
> return constantExpression;
> } {code}
> The return type of the corresponding accept function is more general:
> {code:java}
> @Override public Expression accept(Shuttle shuttle) {
> return shuttle.visit(this);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5686) Generalize return types of the linq4j expression shuttle
[
https://issues.apache.org/jira/browse/CALCITE-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5686:
-
Fix Version/s: (was: 1.35.0)
> Generalize return types of the linq4j expression shuttle
>
>
> Key: CALCITE-5686
> URL: https://issues.apache.org/jira/browse/CALCITE-5686
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Assignee: Thomas Rebele
>Priority: Major
>
> The following block in org.apache.calcite.linq4j.tree.Shuttle prevents
> replacing constants with other expressions:
> {code:java}
> public ConstantExpression visit(ConstantExpression constantExpression) {
> return constantExpression;
> } {code}
> The return type of the corresponding accept function is more general:
> {code:java}
> @Override public Expression accept(Shuttle shuttle) {
> return shuttle.visit(this);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5279) Firebolt does not support BETWEEN ASYMMETRIC
[ https://issues.apache.org/jira/browse/CALCITE-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738277#comment-17738277 ] Julian Hyde commented on CALCITE-5279: -- I have removed 'fixVersion = 1.35.0' because there has been no activity recently and the PR has conflicts. [~jbal...@gmail.com] or [~Aymeric-Dispa], Could one of you modify the PR and ping me? If it arrives in time I will try to get it into the 1.35.0 release. > Firebolt does not support BETWEEN ASYMMETRIC > > > Key: CALCITE-5279 > URL: https://issues.apache.org/jira/browse/CALCITE-5279 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.31.0, 1.32.0 >Reporter: Aymeric Dispa >Assignee: Aymeric Dispa >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The Asymmetric keyword is not supported by Firebolt. > The dialect must be changed so that the keyword that is not supported is > simply not included in the query -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5279) Firebolt does not support BETWEEN ASYMMETRIC
[ https://issues.apache.org/jira/browse/CALCITE-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5279: - Fix Version/s: (was: 1.35.0) > Firebolt does not support BETWEEN ASYMMETRIC > > > Key: CALCITE-5279 > URL: https://issues.apache.org/jira/browse/CALCITE-5279 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.31.0, 1.32.0 >Reporter: Aymeric Dispa >Assignee: Aymeric Dispa >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The Asymmetric keyword is not supported by Firebolt. > The dialect must be changed so that the keyword that is not supported is > simply not included in the query -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738270#comment-17738270
]
Julian Hyde edited comment on CALCITE-5805 at 6/28/23 7:47 PM:
---
This is a duplicate of CALCITE-985. We never completed implementation of MERGE.
I haven't checked the PR, but it should complete implementation of MERGE and
add tets accordingly. Also it should enable
{{SqlToRelConverterTest.testMerge()}}.
was (Author: julianhyde):
This is a duplicate of CALCITE-985. We never completed implementation of MERGE.
I haven't checked the PR, but it should complete implementation of MERGE and
add tets accordingly. Also it should enable
{{SqlToRelConverterTest.testMerge()}.
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> For the unit test.
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
> * If we enable `assert`, the error will be *AssertionError.*
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
> {code}
> * If we disable `assert`, the error will be *NullPointerException.*
> {code:java}
> java.lang.NullPointerException: rowType
> at java.util.Objects.requireNonNull(Objects.java:228)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
[jira] [Resolved] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5805.
--
Fix Version/s: 1.35.0
Resolution: Duplicate
This is a duplicate of CALCITE-985. We never completed implementation of MERGE.
I haven't checked the PR, but it should complete implementation of MERGE and
add tets accordingly. Also it should enable
{{SqlToRelConverterTest.testMerge()}.
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> For the unit test.
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
> * If we enable `assert`, the error will be *AssertionError.*
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
> {code}
> * If we disable `assert`, the error will be *NullPointerException.*
> {code:java}
> java.lang.NullPointerException: rowType
> at java.util.Objects.requireNonNull(Objects.java:228)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
>
[jira] [Commented] (CALCITE-5681) Support authorization via GRANT and REVOKE DDL commands
[
https://issues.apache.org/jira/browse/CALCITE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738267#comment-17738267
]
Julian Hyde commented on CALCITE-5681:
--
What is the equivalent syntax in Postgres? I'd guess something like 'grant all
on s.* to user' but I haven't checked. It often makes sense to follow Postgres.
Variable-depth schemas are unique to Calcite. Maybe we will need special syntax
for the root schema.
> Support authorization via GRANT and REVOKE DDL commands
> ---
>
> Key: CALCITE-5681
> URL: https://issues.apache.org/jira/browse/CALCITE-5681
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
>
> Support authorization via GRANT and REVOKE DDL commands.
> While CALCITE-2194 describes how authorization could be built into the schema
> (e.g. user1 can see tables table1 and table2), it requires people to create
> their own Schema objects. This feature would add GRANT and REVOKE commands to
> the DDL parser in the "server" component.
> The syntax is TBD but would look something like this:
> {code:java}
> GRANT SELECT ON TABLE table1, table2 TO user1;
> REVOKE ALL ON table1 FROM user1; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5747) Conflicting FLOOR return type between Calcite and BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-5747.
---
Resolution: Fixed
Merged via
[08b94e|https://github.com/apache/calcite/commit/08b94e33ec96e1c100faa466f1a9e701626c7e91]
> Conflicting FLOOR return type between Calcite and BigQuery
> --
>
> Key: CALCITE-5747
> URL: https://issues.apache.org/jira/browse/CALCITE-5747
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> In Calcite, the {{FLOOR}} function return type is set to
> {{ARG0_OR_EXACT_NO_SCALE}}. This means that if the result is not a decimal
> with scale 0, it falls back to whatever the type of {{ARG0}} is
> ([source|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L628-L633]).
>
> For instance, if the {{FLOOR}} function is called with an argument of type
> {{BIGINT}}, the return type will be {{BIGINT}} because it is not a decimal
> with scale 0, so it falls back to {{ARG0}}.
> The issue lies in the fact that BigQuery has different behavior for inferring
> the return type. This inference is done according to [these
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#floor].
>
> This conflicts with Calcite if the argument provided to the {{FLOOR}}
> function is an {{BIGINT}} , {{BigQuery}} returns an {{DOUBLE}} (FLOAT64 in BQ
> terms) while Calcite would return a {{BIGINT}}.
> A consequence of this problem may be seen in the following query:
> {{SELECT TIMESTAMP_SECONDS(CAST(FLOOR(CAST(3 AS BIGINT)) AS BIGINT)}}
> Calcite simplifies the query to {{SELECT TIMESTAMP_SECONDS(FLOOR(3)}} because
> the return type is already a {{BIGINT}} so the cast is deemed unnecessary.
> (The cast within the floor function is just to ensure the operand is of type
> {{BIGINT}} for illustrative purposes).
> When BigQuery receives this query, it throws an error because the return type
> of FLOOR(3) is a {{DOUBLE}} (FLOAT64 in BigQuery terms) and the
> {{TIMESTAMP_SECONDS}} function is expecting an integer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5615) Run SQLLogicTests using Calcite
[ https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu updated CALCITE-5615: - Fix Version/s: 1.35.0 > Run SQLLogicTests using Calcite > --- > > Key: CALCITE-5615 > URL: https://issues.apache.org/jira/browse/CALCITE-5615 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.35.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sqllogictest is a program designed to verify that an SQL database engine > computes correct results by comparing the results to identical queries from > other SQL database engines. > https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki > The nice thing about SLT is that it contains more than 7 million tests. The > tests only cover the core of SQL, ideally the portable part across all > engines. They only test integers, doubles, and strings. So they could > probably be part of the Calcite slow tests. > The tests should be structured so that any query execution engine can be used. > I plan to contribute such an implementation if people think it is useful, but > I haven't yet worked out all the details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5687) lazy get scheme
[ https://issues.apache.org/jira/browse/CALCITE-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738264#comment-17738264 ] Julian Hyde commented on CALCITE-5687: -- I removed 'fixVersion = 1.35.0'. Even though there is a PR, it doesn't seem ready. > lazy get scheme > --- > > Key: CALCITE-5687 > URL: https://issues.apache.org/jira/browse/CALCITE-5687 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.34.0 >Reporter: yiku123 >Assignee: yiku123 >Priority: Major > > scence：now i use calcite on my web application > use and problem ：when rewrite > org.apache.calcite.schema.impl.AbstractSchema#getTableMap method ,i must to > provide all table scheme informations,but i only want to provide scheme > when my SQL actually use a table。because i don't want my application load > many schemes event if not to use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5687) lazy get scheme
[ https://issues.apache.org/jira/browse/CALCITE-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5687: - Fix Version/s: (was: 1.35.0) > lazy get scheme > --- > > Key: CALCITE-5687 > URL: https://issues.apache.org/jira/browse/CALCITE-5687 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.34.0 >Reporter: yiku123 >Assignee: yiku123 >Priority: Major > > scence：now i use calcite on my web application > use and problem ：when rewrite > org.apache.calcite.schema.impl.AbstractSchema#getTableMap method ,i must to > provide all table scheme informations,but i only want to provide scheme > when my SQL actually use a table。because i don't want my application load > many schemes event if not to use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5708) Change SUBSTRING result if either of parameters is NULL literal
[
https://issues.apache.org/jira/browse/CALCITE-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738262#comment-17738262
]
Julian Hyde commented on CALCITE-5708:
--
[~Runking] and [~zstan], This is marked 'fixVersion = 1.35.0' and the release
is rapidly approaching. In the next 24 hours, can we agree criteria so that
this can be finished?
> Change SUBSTRING result if either of parameters is NULL literal
> ---
>
> Key: CALCITE-5708
> URL: https://issues.apache.org/jira/browse/CALCITE-5708
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: patch-available, pull-request-available
> Fix For: 1.35.0
>
>
> According to standard:
> {noformat}
> 6.18
> ...
> 3)If is specified, then:
> ...
> c) If either C, S, or L is the null value, then the result of the substring function> is
> the null value.
> {noformat}
> calcite not follow this rule for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4987) JDBC adapter generates incorrect query when ORDER BY alias collides with field in SELECT ITEM
[
https://issues.apache.org/jira/browse/CALCITE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738261#comment-17738261
]
Julian Hyde commented on CALCITE-4987:
--
[~yanjing.wang], I have removed 'fixVersion = 1.35.0' because the PR has
conflicts. If you rebase the PR and remove the conflicts I will try to get it
into the upcoming release.
> JDBC adapter generates incorrect query when ORDER BY alias collides with
> field in SELECT ITEM
> -
>
> Key: CALCITE-4987
> URL: https://issues.apache.org/jira/browse/CALCITE-4987
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I reproduce with the following query.
>
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY shelf_width{code}
> you must have noticed that the shelf_width alias is same with field
> 'shelf_width' in sum.
> I expected the query hasn't changed when I test in RelToSqlConverterTest. But
> I get unexpected query is
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY sum(shelf_width)
> {code}
> the unexpected query is not valid in the dialect which support order by
> alias conformance.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4987) JDBC adapter generates incorrect query when ORDER BY alias collides with field in SELECT ITEM
[
https://issues.apache.org/jira/browse/CALCITE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4987:
-
Fix Version/s: (was: 1.35.0)
> JDBC adapter generates incorrect query when ORDER BY alias collides with
> field in SELECT ITEM
> -
>
> Key: CALCITE-4987
> URL: https://issues.apache.org/jira/browse/CALCITE-4987
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
> Environment: jdk8
>Reporter: yanjing.wang
>Assignee: yanjing.wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I reproduce with the following query.
>
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY shelf_width{code}
> you must have noticed that the shelf_width alias is same with field
> 'shelf_width' in sum.
> I expected the query hasn't changed when I test in RelToSqlConverterTest. But
> I get unexpected query is
> {code:java}
> SELECT sum(shelf_width) as shelf_width FROM product ORDER BY sum(shelf_width)
> {code}
> the unexpected query is not valid in the dialect which support order by
> alias conformance.
>
--
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=17738257#comment-17738257 ] Julian Hyde commented on CALCITE-5737: -- I removed 'fixVersion = 1.35.0'. It's too much to do this month. > 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-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5737: - Fix Version/s: (was: 1.35.0) > 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] [Resolved] (CALCITE-5762) Create class TestUnsafe, that contains unsafe methods used by tests
[
https://issues.apache.org/jira/browse/CALCITE-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5762.
--
Resolution: Fixed
Fixed in
[644a3f07|https://github.com/apache/calcite/commit/644a3f0727038e955791ad068c01d6dffc27a34d].
> Create class TestUnsafe, that contains unsafe methods used by tests
> ---
>
> Key: CALCITE-5762
> URL: https://issues.apache.org/jira/browse/CALCITE-5762
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.35.0
>
>
> Create {{class TestUnsafe}}, that contains unsafe methods used by tests.
> Similar to the existing {{class Unsafe}}, this will be excluded from
> forbidden-apis checks. But it contains sensitive commands (e.g.
> {{java.lang.Runtime#exec}})) that are safe to use in tests but must not be on
> the runtime class path.
> Move some methods from {{class ConcurrentTestCommandScript}} to {{class
> TestUnsafe}}, and remove the former class from the forbidden-apis allow-list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5765) Add LintTest, to apply custom lint rules to source code
[
https://issues.apache.org/jira/browse/CALCITE-5765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5765.
--
Resolution: Fixed
Fixed in
[c0e6ba26|https://github.com/apache/calcite/commit/c0e6ba264b3e522010a982ed35de9f3dd03be6af].
> Add LintTest, to apply custom lint rules to source code
> ---
>
> Key: CALCITE-5765
> URL: https://issues.apache.org/jira/browse/CALCITE-5765
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.35.0
>
>
> Add {{LintTest}}, to apply custom lint rules to source code. If there are any
> violations, the test prints the warnings and fails.
> Example lint rules:
> * Javadoc paragraphs must be separated by blank lines
> * Javadoc paragraphs must start with {{}}
> * In Javadoc, there must be a blank line between the description
> and the first {{@param}}
> {{LintTest}} is built using Puffin (see CALCITE-5764), which allows regular
> expressions to be applied to individual lines and state that is carried from
> one line to the next. (The regular expressions provided by Autostyle are too
> cumbersome to match multi-line patterns.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5706) Add class PairList
[
https://issues.apache.org/jira/browse/CALCITE-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5706.
--
Fix Version/s: 1.35.0
Resolution: Fixed
Fixed in
[4219c993|https://github.com/apache/calcite/commit/4219c993b642f7ba66f7b9a28a66f4616eb1168a].
> Add class PairList
> --
>
> Key: CALCITE-5706
> URL: https://issues.apache.org/jira/browse/CALCITE-5706
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> Add a {{class PairList}} which is an implementation of {{List V>}} backed by a single list. Each entry to the {{PairList}} corresponds to
> two entries in the backing list, but we save ourselves the effort of creating
> {{Map.Entry}} wrappers.
> A {{PairList}} can be used to build two lists in parallel (e.g. a list of
> field types and field names that will be converted to a struct type); it can
> also be used to build maps.
> It has a {{forEach(BiConsumer)}} method to allow the list to be
> deconstructed without creating intermediate entries.
> Potentially also {{toImmutableMap}} and {{toHashMap}} methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5764) Puffin, an Awk for Java
[
https://issues.apache.org/jira/browse/CALCITE-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5764.
--
Resolution: Fixed
Fixed in
[267326d1|https://github.com/apache/calcite/commit/267326d15e347df18af816127b5e5cef6a8bf3d4].
> Puffin, an Awk for Java
> ---
>
> Key: CALCITE-5764
> URL: https://issues.apache.org/jira/browse/CALCITE-5764
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.35.0
>
>
> Create Puffin, which allows a programming model similar to the {{awk}}
> scripting language.
> An {{awk}} program is a collection of rules, each of which is a pair: a
> predicate and an action. For each line in a file, the rules are applied in
> sequence, and if the predicate evaluates to true, the action is executed.
> Then {{awk}} goes on to the next file.
> Here is a simple {{awk}} script that counts the number of non-comment lines
> in a file:
> {code}
> /^#/ {
> ++n;
> }
> END {
> printf("counter: %d\n", n);
> }
> {code}
> Here is the equivalent Puffin program:
> {code}
> Puffin.Program program =
> Puffin.builder(() -> Unit.INSTANCE, u -> new AtomicInteger())
> .add(line -> !line.startsWith("#"),
> line -> line.state().incrementAndGet())
> .after(context ->
> context.println("counter: " + context.state().get()))
> .build();
> {code}
> In {{Puffin}}, each predicate is a {{Predicate>}}, and each action is a
> {{Consumer}}. {{Line}} is a data structure that gives access to the
> text of the line, regular expression matching, and file-local and global
> state.
> {{Puffin}} allows thread-safe parallel processing of multiple files (or more
> generally sources, including URLs). File-local state is allocated by a
> factory, and each file is processed in a single thread. Therefore rules do
> not need to coordinate with rules processing other files.
> Global state is also allocated by a factory, but it is shared, and rules must
> coordinate when they access it. In the above example, {{u -> new
> AtomicInteger()}} is the factory that creates global state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5756) Expand ProjectJoinRemoveRule to support inner join removal by using the foreign-unique constraints
[
https://issues.apache.org/jira/browse/CALCITE-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738176#comment-17738176
]
Alessandro Solimando commented on CALCITE-5756:
---
I have removed the fixVersion previously set to 1.3.5 as the release will
happen soon, and there are still some open discussions around the validity of
the approach
> Expand ProjectJoinRemoveRule to support inner join removal by using the
> foreign-unique constraints
> --
>
> Key: CALCITE-5756
> URL: https://issues.apache.org/jira/browse/CALCITE-5756
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: winds
>Assignee: winds
>Priority: Major
> Labels: pull-request-available
>
> Join elimination is a useful optmize improvement.
> Consider a query that joins the two tables but does not make use of the Dept
> columns:
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp, Dept
> WHERE Emp.deptno = Dept.dno {code}
> Assuming Emp.deptno is the foreign-key and is non-null, Dept.dno is the
> unique-key. The sql above can be rewritten as following. remove the Dept
> table without affecting the resultset.
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp {code}
> Without redundant join elimination, this query execution may perform poorly.
> The optimize improvement is also available in SQL Server, Oracle and
> Snowflake and so on.
> In Calcite, i think that is also useful. The infrastructure that join
> elimination depend on is already available.
> The main steps are as follows:
> 1. Analyse the column used by project, and then split them to left and right
> side.
> 2. Acccording to the project info above and outer join type, bail out in some
> scene.
> 3. Get join info such as join keys.
> 4. For inner join check foreign and unique keys, these may use
> RelMetadataQuery#getForeignKeys(newly add, similar to
> RelMetadataQuery#getUniqueKeys),
> RelOptTable#getReferentialConstraints.
> 5. Check removing side join keys are areColumnsUnique both for outer join and
> inner join.
> 6. If all done, calculate the fianl project and transform.
> Please help me to check the improvement whether is useful or not.
> And i would like to add this improvement to Calcite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5756) Expand ProjectJoinRemoveRule to support inner join removal by using the foreign-unique constraints
[
https://issues.apache.org/jira/browse/CALCITE-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Solimando updated CALCITE-5756:
--
Fix Version/s: (was: 1.35.0)
> Expand ProjectJoinRemoveRule to support inner join removal by using the
> foreign-unique constraints
> --
>
> Key: CALCITE-5756
> URL: https://issues.apache.org/jira/browse/CALCITE-5756
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: winds
>Assignee: winds
>Priority: Major
> Labels: pull-request-available
>
> Join elimination is a useful optmize improvement.
> Consider a query that joins the two tables but does not make use of the Dept
> columns:
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp, Dept
> WHERE Emp.deptno = Dept.dno {code}
> Assuming Emp.deptno is the foreign-key and is non-null, Dept.dno is the
> unique-key. The sql above can be rewritten as following. remove the Dept
> table without affecting the resultset.
> {code:java}
> SELECT Emp.name, Emp.salary
> FROM Emp {code}
> Without redundant join elimination, this query execution may perform poorly.
> The optimize improvement is also available in SQL Server, Oracle and
> Snowflake and so on.
> In Calcite, i think that is also useful. The infrastructure that join
> elimination depend on is already available.
> The main steps are as follows:
> 1. Analyse the column used by project, and then split them to left and right
> side.
> 2. Acccording to the project info above and outer join type, bail out in some
> scene.
> 3. Get join info such as join keys.
> 4. For inner join check foreign and unique keys, these may use
> RelMetadataQuery#getForeignKeys(newly add, similar to
> RelMetadataQuery#getUniqueKeys),
> RelOptTable#getReferentialConstraints.
> 5. Check removing side join keys are areColumnsUnique both for outer join and
> inner join.
> 6. If all done, calculate the fianl project and transform.
> Please help me to check the improvement whether is useful or not.
> And i would like to add this improvement to Calcite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5803) Migrate Avatica to Gradle 8.1.1
[ https://issues.apache.org/jira/browse/CALCITE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richárd Antal reassigned CALCITE-5803: -- Assignee: Richárd Antal > Migrate Avatica to Gradle 8.1.1 > --- > > Key: CALCITE-5803 > URL: https://issues.apache.org/jira/browse/CALCITE-5803 > Project: Calcite > Issue Type: Task >Reporter: Richárd Antal >Assignee: Richárd Antal >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5803) Migrate Avatica to Gradle 8.1.1
[ https://issues.apache.org/jira/browse/CALCITE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richárd Antal updated CALCITE-5803: --- Summary: Migrate Avatica to Gradle 8.1.1 (was: Migrate Avatica to Gradle 8.0.0) > Migrate Avatica to Gradle 8.1.1 > --- > > Key: CALCITE-5803 > URL: https://issues.apache.org/jira/browse/CALCITE-5803 > Project: Calcite > Issue Type: Task >Reporter: Richárd Antal >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5803) Migrate Avatica to Gradle 8.0.0
[ https://issues.apache.org/jira/browse/CALCITE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5803: Labels: pull-request-available (was: ) > Migrate Avatica to Gradle 8.0.0 > --- > > Key: CALCITE-5803 > URL: https://issues.apache.org/jira/browse/CALCITE-5803 > Project: Calcite > Issue Type: Task >Reporter: Richárd Antal >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-4679) Search/sarg simplification leaves is not null(literal) unsimplified
[
https://issues.apache.org/jira/browse/CALCITE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-4679.
Resolution: Fixed
> Search/sarg simplification leaves is not null(literal) unsimplified
> ---
>
> Key: CALCITE-4679
> URL: https://issues.apache.org/jira/browse/CALCITE-4679
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Vladimir Sitnikov
>Assignee: Runkang He
>Priority: Major
> Fix For: 1.35.0
>
>
> Case: {{SEARCH(100500, Sarg[=])}} (Sarg[=] is "all values match, unknown as
> unknown").
> While the issue does not look severe, it results in rex fuzzer false
> positives, so it might mask true bugs.
> Expected: {{true}}
> Actual:
> {noformat}
> unknown as unknown: OR(IS NOT NULL(0), null)
> unknown as false: IS NOT NULL(0)
> unknown as true: true <-- finally got the right answer
> {noformat}
> Test:
> {code:java}
> checkSimplify(
> rexBuilder.makeCall(
> SqlStdOperatorTable.SEARCH,
> literal(BigDecimal.ZERO),
> rexBuilder.makeSearchArgumentLiteral(
> Sarg.of(RexUnknownAs.UNKNOWN,
> ImmutableRangeSet.of(Range.all())),
> tInt())),
> "true"
> );
> {code}
> ---
> fuzzer:
> {code:java}
> @Test void singleFuzzyTest() {
> Random r = new Random();
> r.setSeed(-8889103384303613092L);
> RexFuzzer fuzzer = new RexFuzzer(rexBuilder, typeFactory);
> generateRexAndCheckTrueFalse(fuzzer, r);
> }{code}
> {noformat}
> AssertionFailedError: SEARCH(100500, Sarg[=])
> rexBuilder.makeCall(SqlStdOperatorTable.SEARCH, literal(100500),
> literal(Sarg[=])) isAlwaysTrue, so it should simplify to TRUE unknownAsFalse
> ==> expected: but was:
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:69)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:188)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1146)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:251)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAsAndShrink(RexProgramFuzzyTest.java:202)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:165)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.generateRexAndCheckTrueFalse(RexProgramFuzzyTest.java:454)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.singleFuzzyTest(RexProgramFuzzyTest.java:463)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5771) Apply two different NULL semantics for CONCAT function(enabled in MySQL, Postgresql, BigQuery and MSSQL)
[ https://issues.apache.org/jira/browse/CALCITE-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L resolved CALCITE-5771. Fix Version/s: 1.35.0 Resolution: Fixed > Apply two different NULL semantics for CONCAT function(enabled in MySQL, > Postgresql, BigQuery and MSSQL) > > > Key: CALCITE-5771 > URL: https://issues.apache.org/jira/browse/CALCITE-5771 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: ZheHu >Assignee: ZheHu >Priority: Major > Labels: pull-request-available > Fix For: 1.35.0 > > > We now have one CONCAT_FUNCTION which is enabled in MySQL, Postgresql, > BigQuery, it always returns NULL when any of the arguments is NULL, and it > accepts at least 2 arguments. > The following table describes how different database products define CONCAT > function: > ||DB Product||Argument type in CONCAT||Argument num in CONCAT||Result|| > |MySQL|string|at least 1|returns null if any argument is null, otherwise > return string| > |BigQuery|string|at least 1|returns null if any argument is null, otherwise > return string| > |Postgresql|any(cast to string)|at least 1|always return string, null is > treated as empty string| > |MSSQL|string|2 ~ 254|always return string, null is treated as empty string| > For MySQL and BigQuery, we can reuse the current CONCAT_FUNCTION(but need to > change the accepted argument number). We also need another CONCAT function > for Postgresql and MSSQL that treats NULL as empty String. And they both > accept at least 1 argument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CALCITE-4679) Search/sarg simplification leaves is not null(literal) unsimplified
[
https://issues.apache.org/jira/browse/CALCITE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L reopened CALCITE-4679:
> Search/sarg simplification leaves is not null(literal) unsimplified
> ---
>
> Key: CALCITE-4679
> URL: https://issues.apache.org/jira/browse/CALCITE-4679
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Vladimir Sitnikov
>Assignee: Runkang He
>Priority: Major
> Fix For: 1.35.0
>
>
> Case: {{SEARCH(100500, Sarg[=])}} (Sarg[=] is "all values match, unknown as
> unknown").
> While the issue does not look severe, it results in rex fuzzer false
> positives, so it might mask true bugs.
> Expected: {{true}}
> Actual:
> {noformat}
> unknown as unknown: OR(IS NOT NULL(0), null)
> unknown as false: IS NOT NULL(0)
> unknown as true: true <-- finally got the right answer
> {noformat}
> Test:
> {code:java}
> checkSimplify(
> rexBuilder.makeCall(
> SqlStdOperatorTable.SEARCH,
> literal(BigDecimal.ZERO),
> rexBuilder.makeSearchArgumentLiteral(
> Sarg.of(RexUnknownAs.UNKNOWN,
> ImmutableRangeSet.of(Range.all())),
> tInt())),
> "true"
> );
> {code}
> ---
> fuzzer:
> {code:java}
> @Test void singleFuzzyTest() {
> Random r = new Random();
> r.setSeed(-8889103384303613092L);
> RexFuzzer fuzzer = new RexFuzzer(rexBuilder, typeFactory);
> generateRexAndCheckTrueFalse(fuzzer, r);
> }{code}
> {noformat}
> AssertionFailedError: SEARCH(100500, Sarg[=])
> rexBuilder.makeCall(SqlStdOperatorTable.SEARCH, literal(100500),
> literal(Sarg[=])) isAlwaysTrue, so it should simplify to TRUE unknownAsFalse
> ==> expected: but was:
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:69)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:188)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1146)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:251)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAsAndShrink(RexProgramFuzzyTest.java:202)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.checkUnknownAs(RexProgramFuzzyTest.java:165)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.generateRexAndCheckTrueFalse(RexProgramFuzzyTest.java:454)
> at
> org.apache.calcite.test.fuzzer.RexProgramFuzzyTest.singleFuzzyTest(RexProgramFuzzyTest.java:463)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (CALCITE-5757) Incorrect return type for BigQuery TRUNC functions
[
https://issues.apache.org/jira/browse/CALCITE-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L reopened CALCITE-5757:
> Incorrect return type for BigQuery TRUNC functions
> --
>
> Key: CALCITE-5757
> URL: https://issues.apache.org/jira/browse/CALCITE-5757
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> This is written in Calcite terms, a Calcite {{TIMESTAMP}} is a BigQuery
> {{DATETIME}} and a Calcite {{TIMESTAMP_LTZ}} is a BigQuery {{TIMESTAMP}}
> The four BigQuery {{TRUNC}} functions: {{{}DATE_TRUNC{}}},
> {{{}DATETIME_TRUNC{}}}, {{{}TIME_TRUNC{}}}, and {{TIMESTAMP_TRUNC}} have
> varying return types based on (1) which function and (2) the supplied
> datetime type. The return type can be inferred according to this chart:
> |FUNC/TYPE|DATE|TIMESTAMP|TIME|TS w/ LTZ|
> |DATE_TRUNC|DATE|TIMESTAMP|INVALID|TS w/ LTZ|
> |DATETIME_TRUNC|TIMESTAMP|TIMESTAMP|INVALID|TS w/ LTZ|
> |TIME_TRUNC|INVALID|INVALID|TIME|INVALID|
> |TIMESTAMP_TRUNC|TIMESTAMP|TIMESTAMP|INVALID|TS w/ LTZ|
> The opened PR corrects the current implementations to match this chart,
> primarily by adjusting the set return types in the operator table, and also
> converting {{DATES}} to {{TIMESTAMPS}} in the convertlet table for the
> {{DATETIME_TRUNC}} and {{TIMESTAMP_TRUNC}} functions.
> [Relevant
> Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp_trunc]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5757) Incorrect return type for BigQuery TRUNC functions
[
https://issues.apache.org/jira/browse/CALCITE-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-5757.
Fix Version/s: 1.35.0
Resolution: Fixed
> Incorrect return type for BigQuery TRUNC functions
> --
>
> Key: CALCITE-5757
> URL: https://issues.apache.org/jira/browse/CALCITE-5757
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.35.0
>
>
> This is written in Calcite terms, a Calcite {{TIMESTAMP}} is a BigQuery
> {{DATETIME}} and a Calcite {{TIMESTAMP_LTZ}} is a BigQuery {{TIMESTAMP}}
> The four BigQuery {{TRUNC}} functions: {{{}DATE_TRUNC{}}},
> {{{}DATETIME_TRUNC{}}}, {{{}TIME_TRUNC{}}}, and {{TIMESTAMP_TRUNC}} have
> varying return types based on (1) which function and (2) the supplied
> datetime type. The return type can be inferred according to this chart:
> |FUNC/TYPE|DATE|TIMESTAMP|TIME|TS w/ LTZ|
> |DATE_TRUNC|DATE|TIMESTAMP|INVALID|TS w/ LTZ|
> |DATETIME_TRUNC|TIMESTAMP|TIMESTAMP|INVALID|TS w/ LTZ|
> |TIME_TRUNC|INVALID|INVALID|TIME|INVALID|
> |TIMESTAMP_TRUNC|TIMESTAMP|TIMESTAMP|INVALID|TS w/ LTZ|
> The opened PR corrects the current implementations to match this chart,
> primarily by adjusting the set return types in the operator table, and also
> converting {{DATES}} to {{TIMESTAMPS}} in the convertlet table for the
> {{DATETIME_TRUNC}} and {{TIMESTAMP_TRUNC}} functions.
> [Relevant
> Docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp_trunc]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (CALCITE-5771) Apply two different NULL semantics for CONCAT function(enabled in MySQL, Postgresql, BigQuery and MSSQL)
[ https://issues.apache.org/jira/browse/CALCITE-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L reopened CALCITE-5771: > Apply two different NULL semantics for CONCAT function(enabled in MySQL, > Postgresql, BigQuery and MSSQL) > > > Key: CALCITE-5771 > URL: https://issues.apache.org/jira/browse/CALCITE-5771 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: ZheHu >Assignee: ZheHu >Priority: Major > Labels: pull-request-available > > We now have one CONCAT_FUNCTION which is enabled in MySQL, Postgresql, > BigQuery, it always returns NULL when any of the arguments is NULL, and it > accepts at least 2 arguments. > The following table describes how different database products define CONCAT > function: > ||DB Product||Argument type in CONCAT||Argument num in CONCAT||Result|| > |MySQL|string|at least 1|returns null if any argument is null, otherwise > return string| > |BigQuery|string|at least 1|returns null if any argument is null, otherwise > return string| > |Postgresql|any(cast to string)|at least 1|always return string, null is > treated as empty string| > |MSSQL|string|2 ~ 254|always return string, null is treated as empty string| > For MySQL and BigQuery, we can reuse the current CONCAT_FUNCTION(but need to > change the accepted argument number). We also need another CONCAT function > for Postgresql and MSSQL that treats NULL as empty String. And they both > accept at least 1 argument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5681) Support authorization via GRANT and REVOKE DDL commands
[
https://issues.apache.org/jira/browse/CALCITE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738088#comment-17738088
]
hongyu guo commented on CALCITE-5681:
-
Hi, [~julianhyde]
I have submitted a PR and would appreciate it if you could review it when you
have some time.
Additionally, I have a question I'd like to discuss. I provided syntax like
{code:java}
GRANT ALL on ALL TABLES IN SCHEMA s to user {code}
{{{}{}}}But I'm not sure if I should recursively handle sub-schemas. Also, this
syntax doesn't work for tables under the root schema. Could you please help me
with these questions?
> Support authorization via GRANT and REVOKE DDL commands
> ---
>
> Key: CALCITE-5681
> URL: https://issues.apache.org/jira/browse/CALCITE-5681
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
>
> Support authorization via GRANT and REVOKE DDL commands.
> While CALCITE-2194 describes how authorization could be built into the schema
> (e.g. user1 can see tables table1 and table2), it requires people to create
> their own Schema objects. This feature would add GRANT and REVOKE commands to
> the DDL parser in the "server" component.
> The syntax is TBD but would look something like this:
> {code:java}
> GRANT SELECT ON TABLE table1, table2 TO user1;
> REVOKE ALL ON table1 FROM user1; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738078#comment-17738078
]
Jiajun Xie commented on CALCITE-5805:
-
`select * from emp where deptno is null` is a SqlNode that has been registered
twice.
I think we should avoid duplicate registrations in
`SqlValidatorImpl#registerNamespace`.
Here is PR: https://github.com/apache/calcite/pull/3283
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
>
> For the unit test.
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
> * If we enable `assert`, the error will be *AssertionError.*
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
> at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
> at
> org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
> {code}
> * If we disable `assert`, the error will be *NullPointerException.*
> {code:java}
> java.lang.NullPointerException: rowType
> at java.util.Objects.requireNonNull(Objects.java:228)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
> at
> org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
> at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
> at
[jira] [Updated] (CALCITE-5681) Support authorization via GRANT and REVOKE DDL commands
[
https://issues.apache.org/jira/browse/CALCITE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5681:
Labels: pull-request-available (was: )
> Support authorization via GRANT and REVOKE DDL commands
> ---
>
> Key: CALCITE-5681
> URL: https://issues.apache.org/jira/browse/CALCITE-5681
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
>
> Support authorization via GRANT and REVOKE DDL commands.
> While CALCITE-2194 describes how authorization could be built into the schema
> (e.g. user1 can see tables table1 and table2), it requires people to create
> their own Schema objects. This feature would add GRANT and REVOKE commands to
> the DDL parser in the "server" component.
> The syntax is TBD but would look something like this:
> {code:java}
> GRANT SELECT ON TABLE table1, table2 TO user1;
> REVOKE ALL ON table1 FROM user1; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5805:
Description:
For the unit test.
{code:java}
final String sql = "merge into empnullables e "
+ "using (select * from emp where deptno is null) t "
+ "on e.empno = t.empno "
+ "when matched then update "
+ "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
+ "when not matched then insert (empno, ename, deptno, sal) "
+ "values(t.empno, t.ename, 10, t.sal * .15)";
sql(sql).ok(); // Expected it is ok, but failed{code}
* If we enable `assert`, the error will be *AssertionError.*
{code:java}
java.lang.AssertionError
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
at
org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
at
org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
{code}
* If we disable `assert`, the error will be *NullPointerException.*
{code:java}
java.lang.NullPointerException: rowType
at java.util.Objects.requireNonNull(Objects.java:228)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
at
org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
at
org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
at
[jira] [Updated] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5805:
Description:
For the unit test.
{code:java}
final String sql = "merge into empnullables e "
+ "using (select * from emp where deptno is null) t "
+ "on e.empno = t.empno "
+ "when matched then update "
+ "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
+ "when not matched then insert (empno, ename, deptno, sal) "
+ "values(t.empno, t.ename, 10, t.sal * .15)";
sql(sql).ok(); // Expected it is ok, but failed{code}
* If we enable `assert`, the error will be {*}AssertionError{*}{*}{*}
{code:java}
java.lang.AssertionError
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3741)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
at
org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
at
org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3570)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3444)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3792)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateMerge(SqlValidatorImpl.java:5263)
{code}
* If we disable `assert`, the error will be *NullPointerException*
{code:java}
java.lang.NullPointerException: rowType
at java.util.Objects.requireNonNull(Objects.java:228)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:62)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1144)
at
org.apache.calcite.sql.validate.AbstractNamespace.getRowType(AbstractNamespace.java:119)
at
org.apache.calcite.sql.validate.SelectNamespace.getRowType(SelectNamespace.java:32)
at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:203)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:331)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6672)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6652)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:323)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:956)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:6696)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:54)
at
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:37)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:6235)
at
[jira] [Updated] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5805:
Labels: pull-request-available (was: )
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5805) SqlValidatorImpl throws AssertionError while validating MERGE statement
[
https://issues.apache.org/jira/browse/CALCITE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie updated CALCITE-5805:
Summary: SqlValidatorImpl throws AssertionError while validating MERGE
statement (was: SelectNamespace throws NullPointerException while validating
MERGE statement)
> SqlValidatorImpl throws AssertionError while validating MERGE statement
> ---
>
> Key: CALCITE-5805
> URL: https://issues.apache.org/jira/browse/CALCITE-5805
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
>
> {code:java}
> final String sql = "merge into empnullables e "
> + "using (select * from emp where deptno is null) t "
> + "on e.empno = t.empno "
> + "when matched then update "
> + "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
> + "when not matched then insert (empno, ename, deptno, sal) "
> + "values(t.empno, t.ename, 10, t.sal * .15)";
> sql(sql).ok(); // Expected it is ok, but failed{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5805) SelectNamespace throws NullPointerException while validating MERGE statement
Jiajun Xie created CALCITE-5805:
---
Summary: SelectNamespace throws NullPointerException while
validating MERGE statement
Key: CALCITE-5805
URL: https://issues.apache.org/jira/browse/CALCITE-5805
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Jiajun Xie
Assignee: Jiajun Xie
{code:java}
final String sql = "merge into empnullables e "
+ "using (select * from emp where deptno is null) t "
+ "on e.empno = t.empno "
+ "when matched then update "
+ "set ename = t.ename, deptno = t.deptno, sal = t.sal * .1 "
+ "when not matched then insert (empno, ename, deptno, sal) "
+ "values(t.empno, t.ename, 10, t.sal * .15)";
sql(sql).ok(); // Expected it is ok, but failed{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-1593) JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError: Internal error: Error while applying...
[
https://issues.apache.org/jira/browse/CALCITE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738048#comment-17738048
]
Ulrich Kramer commented on CALCITE-1593:
We fixed a similar problem by changing {{VolcanoPlanner::getCostOrInfinite}} to
{code:java}
private RelOptCost getCostOrInfinite(RelNode rel, RelMetadataQuery mq) {
try {
RelOptCost cost = getCost(rel, mq);
return cost == null ? infCost : cost;
} catch (CyclicMetadataException exc) {
return infCost;
}
}
{code}
> JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError:
> Internal error: Error while applying...
> -
>
> Key: CALCITE-1593
> URL: https://issues.apache.org/jira/browse/CALCITE-1593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.0
>Reporter: George Theodorakis
>Priority: Blocker
> Labels: beginner
>
> I have created my own operators and Convention to apply my custom cost logic.
> I have tried many rules with both Volcano and HepPlanner and everything works
> fine. When I apply LoptOptimizeRule I get the correct output. However, when I
> try to use:
> * JoinPushThroughJoinRule.LEFT,
> * JoinPushThroughJoinRule.RIGHT,
> * JoinAssociateRule.INSTANCE,
> * JoinCommuteRule.INSTANCE
> something goes wrong. I try to apply them in VolcanoPlanner in the same step
> I use my converter rules to change the initial Logical Operators to the
> custom ones.
> I declare them as:
> {code}
> static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_RIGHT = new
> JoinPushThroughJoinRule("JoinPushThroughJoinRule", true, SaberJoinRel.class,
> SaberRelFactories.SABER_LOGICAL_BUILDER);
>
> static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_LEFT = new
> JoinPushThroughJoinRule("JoinPushThroughJoinRule", false, SaberJoinRel.class,
> SaberRelFactories.SABER_LOGICAL_BUILDER);
> static final RelOptRule SABER_JOIN_COMMUTE_RULE = new
> JoinCommuteRule(SaberJoinRel.class, SaberRelFactories.SABER_LOGICAL_BUILDER,
> false);
> {code}
>
> So, when I use the four of them I get:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Internal error: Error
> while applying rule SaberProjectRule, args
> [rel#171:LogicalProject.NONE.[](input=rel#170:Subset#20.LOGICAL.[],rowtime=$8,customerid=$9,phone=$10,rowtime0=$0,orderid=$1,productid=$2,units=$3,customerid0=$4,rowtime00=$5,productid0=$6,description=$7)]
> at org.apache.calcite.util.Util.newInternal(Util.java:792)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:819)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:334)
> at
> org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:308)
> at calcite.planner.SaberPlanner.getLogicalPlan(SaberPlanner.java:257)
> at calcite.Tester.main(Tester.java:183)
> Caused by: java.lang.AssertionError: Internal error: Error occurred while
> applying rule SaberProjectRule
> at org.apache.calcite.util.Util.newInternal(Util.java:792)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:225)
> at
> org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:117)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
> ... 5 more
> Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException
> at
> org.apache.calcite.rel.metadata.CyclicMetadataException.(CyclicMetadataException.java:28)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
> {noformat}
> If it helps, when I don't use JoinCommuteRule I don't get an exception, but I
> get wrong result and when I don't use JoinAssociateRule I get:
> {noformat}Exception in thread "main" java.lang.StackOverflowError
> at
> com.google.common.collect.ImmutableCollection.(ImmutableCollection.java:157)
> at
> com.google.common.collect.ImmutableList.(ImmutableList.java:313)
> at
>
