[jira] [Updated] (CALCITE-6306) JDBC adapter should not generate FILTER (WHERE) in MySQL and StarRocks dialect
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-6306:
Summary: JDBC adapter should not generate FILTER (WHERE) in MySQL and
StarRocks dialect (was: FILTER clauses for aggregate functions are not
supported in MySQL, MariaDB and StarRocks)
> JDBC adapter should not generate FILTER (WHERE) in MySQL and StarRocks dialect
> --
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in [https://modern-sql.com/feature/filter]
> Calcite should not generate the agg() FILTER clause for the MySQL dialect.
> CALCITE-4321 introduced a way to convert the FILTER clause to an aggregation
> function with CASE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6306) FILTER clauses for aggregate functions are not supported in MySQL, MariaDB and StarRocks
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-6306:
Summary: FILTER clauses for aggregate functions are not supported in MySQL,
MariaDB and StarRocks (was: FILTER clauses for aggregate functions are not
supported in MySQL, MariaDB and Starrocks)
> FILTER clauses for aggregate functions are not supported in MySQL, MariaDB
> and StarRocks
>
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in [https://modern-sql.com/feature/filter]
> Calcite should not generate the agg() FILTER clause for the MySQL dialect.
> CALCITE-4321 introduced a way to convert the FILTER clause to an aggregation
> function with CASE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6306) FILTER clauses for aggregate functions are not supported in MySQL, MariaDB and Starrocks
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-6306:
Description:
{code:sql}
mysql> select sum(x) filter (where x = 1) from t;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'(where x = 1) from t' at line 1 {code}
See details in [https://modern-sql.com/feature/filter]
Calcite should not generate the agg() FILTER clause for the MySQL dialect.
CALCITE-4321 introduced a way to convert the FILTER clause to an aggregation
function with CASE.
was:
{code:sql}
mysql> select sum(x) filter (where x = 1) from t;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'(where x = 1) from t' at line 1 {code}
See details in [https://modern-sql.com/feature/filter]
> FILTER clauses for aggregate functions are not supported in MySQL, MariaDB
> and Starrocks
>
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in [https://modern-sql.com/feature/filter]
> Calcite should not generate the agg() FILTER clause for the MySQL dialect.
> CALCITE-4321 introduced a way to convert the FILTER clause to an aggregation
> function with CASE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6306) FILTER clauses for aggregate functions are not supported in MySQL, MariaDB and Starrocks
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-6306:
Description:
{code:sql}
mysql> select sum(x) filter (where x = 1) from t;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'(where x = 1) from t' at line 1 {code}
See details in [https://modern-sql.com/feature/filter]
was:
{code:sql}
mysql> select sum(x) filter (where x = 1) from t;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'(where x = 1) from t' at line 1 {code}
See details in https://modern-sql.com/feature/filter
> FILTER clauses for aggregate functions are not supported in MySQL, MariaDB
> and Starrocks
>
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in [https://modern-sql.com/feature/filter]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6308) Add PostgreSQL functions up to PostgreSQL v14
[
https://issues.apache.org/jira/browse/CALCITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824590#comment-17824590
]
James Duong commented on CALCITE-6308:
--
Thanks [~tanclary] . I've added you to the RANDOM PR:
https://github.com/apache/calcite/pull/3720
> Add PostgreSQL functions up to PostgreSQL v14
> -
>
> Key: CALCITE-6308
> URL: https://issues.apache.org/jira/browse/CALCITE-6308
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: James Duong
>Priority: Minor
>
> Support the following PostgreSQL functions for parity with PostgreSQL 14:
> * REGEXP_LIKE
> ** The Spark version of this is being implemented in CALCITE-6278
> ** The PostgreSQL version requires supporting a 3-arg version that takes in
> flags.
> * REGEXP_REPLACE
> ** There is an existing implementation.
> ** PostgreSQL requires supporting an optional extra flags argument
> * DATE_PART
> ** PostgreSQL and Redshift let the date_part parameter be a string instead
> of a just an enum-like identifier (eg DATE_PART('year', ...) and
> DATE_PART(year, ...) are both supported.
> ** SQL Server does not support using a string here.
> * LOG
> ** We have the BigQuery implementation which has a 1-arg overload that uses
> base e (ln), and a 2-arg overload which is LOG(value, base)
> ** PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the
> order reversed – LOG(base, value)
> * POW
> ** Our existing implementation always returns double.
> ** PostgreSQL allows returning a numeric instead of a double when inputs are
> numeric. Not sure if this makes sense though.
> * RANDOM
> ** This is an alias for RAND(), except it should not support passing in a
> seed.
> * TO_CHAR
> * TO_DATE
> * TO_TIMESTAMP
> ** PostgreSQL supports different format strings than the version we have
> implemented.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6314) Support PostgreSQL RANDOM
[ https://issues.apache.org/jira/browse/CALCITE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6314: Labels: pull-request-available (was: ) > Support PostgreSQL RANDOM > - > > Key: CALCITE-6314 > URL: https://issues.apache.org/jira/browse/CALCITE-6314 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Major > Labels: pull-request-available > > This is an alias for RAND(), except it should not support passing in a seed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-5607) Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee reassigned CALCITE-5607:
---
Assignee: Oliver Lee
> Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5607) Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824580#comment-17824580
]
Oliver Lee edited comment on CALCITE-5607 at 3/8/24 12:35 AM:
--
Yeah that is fair.
I'll just log a new case to update the comments and description then
Edit:
https://issues.apache.org/jira/browse/CALCITE-6316
[https://github.com/apache/calcite/pull/3719]
was (Author: JIRAUSER297744):
Yeah that is fair.
I'll just log a new case to update the comments and description then
> Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6316) Update Javadoc for CALCITE-5607
[ https://issues.apache.org/jira/browse/CALCITE-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6316: Labels: pull-request-available (was: ) > Update Javadoc for CALCITE-5607 > --- > > Key: CALCITE-6316 > URL: https://issues.apache.org/jira/browse/CALCITE-6316 > Project: Calcite > Issue Type: Task >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Trivial > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6316) Update Javadoc for CALCITE-5607
Oliver Lee created CALCITE-6316: --- Summary: Update Javadoc for CALCITE-5607 Key: CALCITE-6316 URL: https://issues.apache.org/jira/browse/CALCITE-6316 Project: Calcite Issue Type: Task Reporter: Oliver Lee Assignee: Oliver Lee -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5607) Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824580#comment-17824580
]
Oliver Lee commented on CALCITE-5607:
-
Yeah that is fair.
I'll just log a new case to update the comments and description then
> Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6315) Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP
James Duong created CALCITE-6315: Summary: Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP Key: CALCITE-6315 URL: https://issues.apache.org/jira/browse/CALCITE-6315 Project: Calcite Issue Type: Sub-task Reporter: James Duong PostgreSQL supports different format strings than the version we have implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6314) Support PostgreSQL RANDOM
James Duong created CALCITE-6314: Summary: Support PostgreSQL RANDOM Key: CALCITE-6314 URL: https://issues.apache.org/jira/browse/CALCITE-6314 Project: Calcite Issue Type: Sub-task Reporter: James Duong This is an alias for RAND(), except it should not support passing in a seed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6313) Support PostgreSQL POW
James Duong created CALCITE-6313: Summary: Support PostgreSQL POW Key: CALCITE-6313 URL: https://issues.apache.org/jira/browse/CALCITE-6313 Project: Calcite Issue Type: Sub-task Reporter: James Duong * Our existing implementation always returns double. * PostgreSQL allows returning a numeric instead of a double when inputs are numeric. Not sure if this makes sense though. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6312) Support PostgreSQL LOG
James Duong created CALCITE-6312: Summary: Support PostgreSQL LOG Key: CALCITE-6312 URL: https://issues.apache.org/jira/browse/CALCITE-6312 Project: Calcite Issue Type: Sub-task Reporter: James Duong * We have the BigQuery implementation which has a 1-arg overload that uses base e (ln), and a 2-arg overload which is LOG(value, base) * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6311) Support PostgreSQL DATE_PART
James Duong created CALCITE-6311:
Summary: Support PostgreSQL DATE_PART
Key: CALCITE-6311
URL: https://issues.apache.org/jira/browse/CALCITE-6311
Project: Calcite
Issue Type: Sub-task
Reporter: James Duong
* PostgreSQL and Redshift let the date_part parameter be a string instead of a
just an enum-like identifier (eg DATE_PART('year', ...) and DATE_PART(year,
...) are both supported.
* SQL Server does not support using a string here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6309) Support PostgreSQL REGEXP_LIKE
[ https://issues.apache.org/jira/browse/CALCITE-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Duong updated CALCITE-6309: - Description: * The Spark version of this is being implemented in CALCITE-6278 * The PostgreSQL version requires supporting a 3-arg version that takes in flags. > Support PostgreSQL REGEXP_LIKE > -- > > Key: CALCITE-6309 > URL: https://issues.apache.org/jira/browse/CALCITE-6309 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > > * The Spark version of this is being implemented in CALCITE-6278 > * The PostgreSQL version requires supporting a 3-arg version that takes in > flags. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6310) Support PostgreSQL REGEXP_REPLACE
James Duong created CALCITE-6310: Summary: Support PostgreSQL REGEXP_REPLACE Key: CALCITE-6310 URL: https://issues.apache.org/jira/browse/CALCITE-6310 Project: Calcite Issue Type: Sub-task Reporter: James Duong * There is an existing implementation. * PostgreSQL requires supporting an optional extra flags argument -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6309) Support PostgreSQL REGEXP_LIKE
James Duong created CALCITE-6309: Summary: Support PostgreSQL REGEXP_LIKE Key: CALCITE-6309 URL: https://issues.apache.org/jira/browse/CALCITE-6309 Project: Calcite Issue Type: Sub-task Reporter: James Duong -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6239) Add a PostGIS dialect that supports ST_ functions
[ https://issues.apache.org/jira/browse/CALCITE-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824563#comment-17824563 ] Bertil Chapuis commented on CALCITE-6239: - [~julianhyde] Thanks a lot, I wouldn't have been able to come up with this elegant solution. I will try to adapt the remaining funtions and to better understand these changes. > Add a PostGIS dialect that supports ST_ functions > - > > Key: CALCITE-6239 > URL: https://issues.apache.org/jira/browse/CALCITE-6239 > Project: Calcite > Issue Type: New Feature > Components: core, spatial >Reporter: Bertil Chapuis >Assignee: Bertil Chapuis >Priority: Minor > Labels: pull-request-available > > Calcite implements support for spatial types (geometry, point, etc.) and > spatial functions (ST_), and it can connect to PostGIS via a JdbcSchema. > However, the Postgresql dialect does not currently handle spatial types and > functions. As a result, Calcite tries to execute the spatial functions at the > level of the JVM instead of pushing them down to postgis. > As a result, the following query gets executed, but the type of the geom > column is incorrect: > SELECT id, geom FROM public.spatial_table > The following query fails with a ClassCastException as Calcite tries to use > the java implementation of the ST_SRID function: > SELECT id, ST_SRID(geom) FROM public.spatial_table > java.lang.ClassCastException: class org.postgresql.util.PGobject cannot be > cast to class org.locationtech.jts.geom.Geometry > (org.postgresql.util.PGobject and org.locationtech.jts.geom.Geometry are in > unnamed module of loader 'app') > In my current understanding, this issue could be addressed with a new > PostgisSqlDialect that extends PostgresqlSqlDialect and adds support for > spatial types and functions. Here is a tentative roadmap: > - Add all the spatial functions to the SqlKind class > - Create a PostgisSqlDialect class that extends PostgresqlSqlDialect > - Add support for the spatial types (geometry) by overriding the getCastSpec > method of the SqlDialect class > - Add support for the spatial functions by overriding the supportsFunction > method of the SqlDialect class > - Add support for the spatial aggregate functions by overriding the > supportsAggregateFunction method of the SqlDialect class -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6308) Add PostgreSQL functions up to PostgreSQL v14
[
https://issues.apache.org/jira/browse/CALCITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824543#comment-17824543
]
Tanner Clary commented on CALCITE-6308:
---
seems like a good initiative, tag me on reviews for individual functions if
you'd like.
> Add PostgreSQL functions up to PostgreSQL v14
> -
>
> Key: CALCITE-6308
> URL: https://issues.apache.org/jira/browse/CALCITE-6308
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: James Duong
>Priority: Minor
>
> Support the following PostgreSQL functions for parity with PostgreSQL 14:
> * REGEXP_LIKE
> ** The Spark version of this is being implemented in CALCITE-6278
> ** The PostgreSQL version requires supporting a 3-arg version that takes in
> flags.
> * REGEXP_REPLACE
> ** There is an existing implementation.
> ** PostgreSQL requires supporting an optional extra flags argument
> * DATE_PART
> ** PostgreSQL and Redshift let the date_part parameter be a string instead
> of a just an enum-like identifier (eg DATE_PART('year', ...) and
> DATE_PART(year, ...) are both supported.
> ** SQL Server does not support using a string here.
> * LOG
> ** We have the BigQuery implementation which has a 1-arg overload that uses
> base e (ln), and a 2-arg overload which is LOG(value, base)
> ** PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the
> order reversed – LOG(base, value)
> * POW
> ** Our existing implementation always returns double.
> ** PostgreSQL allows returning a numeric instead of a double when inputs are
> numeric. Not sure if this makes sense though.
> * RANDOM
> ** This is an alias for RAND(), except it should not support passing in a
> seed.
> * TO_CHAR
> * TO_DATE
> * TO_TIMESTAMP
> ** PostgreSQL supports different format strings than the version we have
> implemented.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6308) Add PostgreSQL functions up to PostgreSQL v14
James Duong created CALCITE-6308:
Summary: Add PostgreSQL functions up to PostgreSQL v14
Key: CALCITE-6308
URL: https://issues.apache.org/jira/browse/CALCITE-6308
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: James Duong
Support the following PostgreSQL functions for parity with PostgreSQL 14:
* REGEXP_LIKE
** The Spark version of this is being implemented in CALCITE-6278
** The PostgreSQL version requires supporting a 3-arg version that takes in
flags.
* REGEXP_REPLACE
** There is an existing implementation.
** PostgreSQL requires supporting an optional extra flags argument
* DATE_PART
** PostgreSQL and Redshift let the date_part parameter be a string instead of
a just an enum-like identifier (eg DATE_PART('year', ...) and DATE_PART(year,
...) are both supported.
** SQL Server does not support using a string here.
* LOG
** We have the BigQuery implementation which has a 1-arg overload that uses
base e (ln), and a 2-arg overload which is LOG(value, base)
** PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the
order reversed – LOG(base, value)
* POW
** Our existing implementation always returns double.
** PostgreSQL allows returning a numeric instead of a double when inputs are
numeric. Not sure if this makes sense though.
* RANDOM
** This is an alias for RAND(), except it should not support passing in a seed.
* TO_CHAR
* TO_DATE
* TO_TIMESTAMP
** PostgreSQL supports different format strings than the version we have
implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6307) Sonar analysis in CI fails with 'java.lang.OutOfMemoryError: Java heap space'
Alessandro Solimando created CALCITE-6307:
-
Summary: Sonar analysis in CI fails with
'java.lang.OutOfMemoryError: Java heap space'
Key: CALCITE-6307
URL: https://issues.apache.org/jira/browse/CALCITE-6307
Project: Calcite
Issue Type: Bug
Components: tests
Affects Versions: 1.36.0
Reporter: Alessandro Solimando
Recently there has been several Sonar failures due to OOM, one example is the
following:
[https://ci-builds.apache.org/blue/organizations/jenkins/Calcite%2FCalcite-sonar/detail/PR-3687/9/pipeline]
In what follows a relevant portion of the execution logs:
{code:java}
Expiring Daemon because JVM heap space is exhausted
> Task :sonar FAILED
Build calcite FAILURE reason:
Execution failed for task ':sonar':
java.lang.OutOfMemoryError: Java heap space
at B.A.A.A.A.D.B(na:26)
at B.A.A.A.A.D.A(na:163)
at B.A.A.A.A.D.B(na:1209)
at B.A.A.A.A.D.B(na:2138)
at B.A.A.A.A.D.B(na:2138)
at B.A.A.A.A.D.B(na:2138)
at B.A.A.A.A.D.B(na:2138)
at B.A.A.A.A.D.B(na:2138)
at B.A.A.A.A.D.B(na:2221)
at B.A.A.A.A.D$_C.A(na:2102)
at com.sonarsource.A.A.U.A(na:3338)
at com.sonarsource.A.A.B.F.A(na:501)
at com.sonarsource.A.A.U.E(na:1630)
at com.sonarsource.A.A.Z.A(na:2867)
at com.sonarsource.A.A.Z.A(na:2409)
at com.sonarsource.A.A.Z.A(na:2223)
at com.sonarsource.A.A.Z.A(na:920)
at com.sonarsource.A.A.Z.E(na:1730)
at com.sonarsource.A.A.Z.A(na:242)
at com.sonarsource.A.A.Z.A(na:671)
at com.sonarsource.A.A.Z.A(na:2244)
at com.sonarsource.A.F.executeChecksOnFunction(na:896)
at com.sonarsource.A.F.executeChecks(na:1668)
at com.sonarsource.A.F.executeSensor(na:1339)
at com.sonarsource.A.F.execute(na:2143)
at
org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:62)
at
org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
at
org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:51)
at
org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
at
org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at
org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at
org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:192)
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':sonar'.
> Java heap space {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6305) Increase coverage of unit tests for the Arrow adapter
[ https://issues.apache.org/jira/browse/CALCITE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Solimando updated CALCITE-6305: -- Summary: Increase coverage of unit tests for the Arrow adapter (was: Increase coverage of unit tests for arrow adapter) > Increase coverage of unit tests for the Arrow adapter > - > > Key: CALCITE-6305 > URL: https://issues.apache.org/jira/browse/CALCITE-6305 > Project: Calcite > Issue Type: Sub-task >Reporter: hongyu guo >Priority: Major > > Add more unit tests for arrow adapter. > for example > * casts, including lossy casts > * complex filter condition > * complex SQL > * and more... > Note: Calcite's support for the arrow feather format is not complete, so > before adding the testing process, we may need to implement new features > first. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Solimando reassigned CALCITE-6265:
-
Assignee: Tim Nieradzik (was: Alessandro Solimando)
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2. Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6278) Add REGEXP, REGEXP_LIKE function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824456#comment-17824456 ] Julian Hyde commented on CALCITE-6278: -- Can you expand on “Since Spark 2.0, string literals (including regex patterns) are unescaped in SQL parser” and give examples? Give a test case that proves it is happening in the parser, not in RLIKE. If unescaping is happening in Spark’s parser, Calcite should also do it in the parser. And in fact this should be a separate Jira. Does the Hive parser have similar behavior? > Add REGEXP, REGEXP_LIKE function (enabled in Spark library) > > > Key: CALCITE-6278 > URL: https://issues.apache.org/jira/browse/CALCITE-6278 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > Attachments: image-2024-03-07-09-32-27-002.png > > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function > [REGEXP|https://spark.apache.org/docs/latest/api/sql/index.html#regexp], > [REGEXP_LIKE|https://spark.apache.org/docs/latest/api/sql/index.html#regexp_like] > # Since this function has the same implementation as the Spark > [RLIKE|https://spark.apache.org/docs/latest/api/sql/index.html#rlike] > function, the implementation can be directly reused. > # Since Spark 2.0, string literals (including regex patterns) are unescaped > in SQL parser, also fix this bug in calcite. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6305) Increase coverage of unit tests for arrow adapter
[ https://issues.apache.org/jira/browse/CALCITE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824453#comment-17824453 ] Julian Hyde commented on CALCITE-6305: -- Should be “Arrow” not “arrow”. Sorry to be pedantic, but this is going to be in our commit log and release notes forever. > Increase coverage of unit tests for arrow adapter > - > > Key: CALCITE-6305 > URL: https://issues.apache.org/jira/browse/CALCITE-6305 > Project: Calcite > Issue Type: Sub-task >Reporter: hongyu guo >Priority: Major > > Add more unit tests for arrow adapter. > for example > * casts, including lossy casts > * complex filter condition > * complex SQL > * and more... > Note: Calcite's support for the arrow feather format is not complete, so > before adding the testing process, we may need to implement new features > first. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6306) FILTER clauses for aggregate functions are not supported in MySQL, MariaDB and Starrocks
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824451#comment-17824451
]
Julian Hyde commented on CALCITE-6306:
--
Can you change the subject so it’s clear which calcite component this issue
affects? As currently written it sounds like a bug in MySQL.
> FILTER clauses for aggregate functions are not supported in MySQL, MariaDB
> and Starrocks
>
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in https://modern-sql.com/feature/filter
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Description:
Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
placeholder in a prepared statement, a {{ClassCastException}} is thrown.
h2. Test case
{{final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
h2. Stack trace
{{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
was:
Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
placeholder in a prepared statement, a {{ClassCastException}} is thrown.
h2. Test case
{{final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ }}{{p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
h2.
Stack trace
{{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2. Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824374#comment-17824374
]
Tim Nieradzik commented on CALCITE-6265:
[~asolimando] The title was indeed confusing. I made it more explicit.
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ }}{{p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2.
> Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Description:
Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
placeholder in a prepared statement, a {{ClassCastException}} is thrown.
h2. Test case
{{final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ }}{{p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
h2.
Stack trace
{{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
was:
The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
placeholder, a _ClassCastException_ is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
{{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ }}{{p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2.
> Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Summary: Type coercion is failing for numeric values in prepared statements
(was: Cannot provide different numeric type as placeholder)
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5893) Wrong NULL operand behavior of ARRAY_CONTAINS/ARRAY_EXCEPT/ARRAY_INTERSECT In Spark Library
[
https://issues.apache.org/jira/browse/CALCITE-5893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao resolved CALCITE-5893.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed via
https://github.com/apache/calcite/commit/42c39a77b9023b75b41e7b77efef9ef8b0b6bb66
thanks [~mbudiu] for reviewing it.
> Wrong NULL operand behavior of ARRAY_CONTAINS/ARRAY_EXCEPT/ARRAY_INTERSECT In
> Spark Library
> ---
>
> Key: CALCITE-5893
> URL: https://issues.apache.org/jira/browse/CALCITE-5893
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The following are the implementations of some array functions in
> calcite({*}Spark Library{*}) that are inconsistent with actual spark behavior.
>
> The reason here is that *null* and *cast (null as xxx)* are treated equally,
> and *NullPolicy* acts on these two situations at the same time and returns
> null directly. However in spark, the former needs to throw an exception, and
> the correct behavior is the latter. (In fact, apache flink also throws an
> exception.) we should throw exception in such case to match Spark behavior.
> *calcite spark:*
> // return null
> select array_contains(array[1, 2], null);
> // return null
> select array_except(array[1, 2, 3], null)
> // return null
> select array_intersect(array[1,2,3], null)
> *actual spark:*
> {code:java}
> // Cannot resolve "array_contains(array(1, 2), NULL)" due to data type
> mismatch: // Null typed values cannot be used as arguments of `array_contains`
> spark-sql (default)> select array_contains(array(1, 2), null); {code}
> {code:java}
> // data type mismatch: Input to function `array_except` should have been two
> "ARRAY" with same element type,
> // but it's ["ARRAY", "VOID"]
> spark-sql (default)> select array_except(array(1, 2, 3), null); {code}
> {code:java}
> // data type mismatch: Input to function `array_intersect` should have been
> two "ARRAY" with same element type,
> // but it's ["ARRAY", "VOID"]
> spark-sql (default)> select array_intersect(array(1,2,3), null); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[
https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824357#comment-17824357
]
hongyu guo commented on CALCITE-2040:
-
[~zabetak] I have addad 5 co-authors, based on the PR2133 and PR2810.
{code:java}
[CALCITE-2040] Create adapter for Apache Arrow
Co-authored-by: Alessandro Solimando
Co-authored-by: Jonathan Swenson
Co-authored-by: Julian Hyde
Co-authored-by: Karshit Shah
Co-authored-by: Michael Mior {code}
> Create adapter for Apache Arrow
> ---
>
> Key: CALCITE-2040
> URL: https://issues.apache.org/jira/browse/CALCITE-2040
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: hongyu guo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: arrow_data.py
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would
> allow people to execute SQL statements, via JDBC or ODBC, on data stored in
> Arrow in-memory format.
> Since Arrow is an in-memory format, it is not as straightforward as reading,
> say, CSV files using the file adapter: an Arrow data set does not have a URL.
> (Unless we use Arrow's
> [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/]
> format, or use an in-memory file system such as Alluxio.) So we would need
> to devise a way of addressing Arrow data sets.
> Also, since Arrow is an extremely efficient format for processing data, it
> would also be good to have Arrow as a calling convention. That is,
> implementations of relational operators such as Filter, Project, Aggregate in
> addition to just TableScan.
> Lastly, when we have an Arrow convention, if we build adapters for file
> formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in
> CALCITE-2025) it would make a lot of sense to translate those formats
> directly into Arrow (applying simple projects and filters first if
> applicable). Those adapters would belong as a "contrib" module in the Arrow
> project better than in Calcite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-2040) Create adapter for Apache Arrow
[ https://issues.apache.org/jira/browse/CALCITE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824299#comment-17824299 ] Stamatis Zampetakis commented on CALCITE-2040: -- Many people contributed to this work so please give add an appropriate mention (use "Co-authored-by" in the commit message) before merging this to main. > Create adapter for Apache Arrow > --- > > Key: CALCITE-2040 > URL: https://issues.apache.org/jira/browse/CALCITE-2040 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: hongyu guo >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: arrow_data.py > > Time Spent: 1.5h > Remaining Estimate: 0h > > Create an adapter for [Apache Arrow|http://arrow.apache.org/]. This would > allow people to execute SQL statements, via JDBC or ODBC, on data stored in > Arrow in-memory format. > Since Arrow is an in-memory format, it is not as straightforward as reading, > say, CSV files using the file adapter: an Arrow data set does not have a URL. > (Unless we use Arrow's > [Feather|https://blog.cloudera.com/blog/2016/03/feather-a-fast-on-disk-format-for-data-frames-for-r-and-python-powered-by-apache-arrow/] > format, or use an in-memory file system such as Alluxio.) So we would need > to devise a way of addressing Arrow data sets. > Also, since Arrow is an extremely efficient format for processing data, it > would also be good to have Arrow as a calling convention. That is, > implementations of relational operators such as Filter, Project, Aggregate in > addition to just TableScan. > Lastly, when we have an Arrow convention, if we build adapters for file > formats (for instance the bioinformatics formats SAM, VCF, FASTQ discussed in > CALCITE-2025) it would make a lot of sense to translate those formats > directly into Arrow (applying simple projects and filters first if > applicable). Those adapters would belong as a "contrib" module in the Arrow > project better than in Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
