[jira] [Commented] (CALCITE-5905) Documentation for CREATE TYPE is incorrect

[Benchao Li (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762275#comment-17762275
 ] 

Benchao Li commented on CALCITE-5905:
-

It sounds good, thanks for providing the reference of Oracle.

> Documentation for CREATE TYPE is incorrect
> --
>
> Key: CALCITE-5905
> URL: https://issues.apache.org/jira/browse/CALCITE-5905
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I have tried to run the example CREATE TYPE statements from this page 
> https://calcite.apache.org/docs/reference.html#declaring-objects-for-user-defined-types
> through the compiler:
> {code:sql}
> CREATE TYPE address_typ AS OBJECT (
>street  VARCHAR2(30),
>cityVARCHAR2(20),
>state   CHAR(2),
>postal_code VARCHAR2(6));
> {code}
> Calcite complains in two places: OBJECT and VARCHAR2. 
> The following compiles fine:
> {code:sql}
> CREATE TYPE address_typ AS (
>street  VARCHAR(30),
>cityVARCHAR(20),
>state   CHAR(2),
>postal_code VARCHAR(6));
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5905) Documentation for CREATE TYPE is incorrect

[Mihai Budiu (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762271#comment-17762271
 ] 

Mihai Budiu commented on CALCITE-5905:
--

Apparently Oracle has a VARCHAR2 data type, which is (currently) an alias for 
VARCHAR:
https://docs.oracle.com/cd/A57673_01/DOC/server/doc/SCN73/ch6.htm#varchar2
The comment in HrSchema that uses VARCHAR2 specifically mentions Oracle, so the 
comment seems correct.
But there is no harm in changing it to VARCHAR.

> Documentation for CREATE TYPE is incorrect
> --
>
> Key: CALCITE-5905
> URL: https://issues.apache.org/jira/browse/CALCITE-5905
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I have tried to run the example CREATE TYPE statements from this page 
> https://calcite.apache.org/docs/reference.html#declaring-objects-for-user-defined-types
> through the compiler:
> {code:sql}
> CREATE TYPE address_typ AS OBJECT (
>street  VARCHAR2(30),
>cityVARCHAR2(20),
>state   CHAR(2),
>postal_code VARCHAR2(6));
> {code}
> Calcite complains in two places: OBJECT and VARCHAR2. 
> The following compiles fine:
> {code:sql}
> CREATE TYPE address_typ AS (
>street  VARCHAR(30),
>cityVARCHAR(20),
>state   CHAR(2),
>postal_code VARCHAR(6));
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5905) Documentation for CREATE TYPE is incorrect

[Benchao Li (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762269#comment-17762269
 ] 

Benchao Li commented on CALCITE-5905:
-

[~mbudiu] Thanks for your PR, it looks good to me.

It seems the PR has been break since there are some force-push on main, could 
you adapt it against latest main branch? And besides, I searched "VARCHAR2" in 
our repo, it seems the comment in {{HrSchema}} also uses it, then we also need 
to correct it, WDYT?

> Documentation for CREATE TYPE is incorrect
> --
>
> Key: CALCITE-5905
> URL: https://issues.apache.org/jira/browse/CALCITE-5905
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I have tried to run the example CREATE TYPE statements from this page 
> https://calcite.apache.org/docs/reference.html#declaring-objects-for-user-defined-types
> through the compiler:
> {code:sql}
> CREATE TYPE address_typ AS OBJECT (
>street  VARCHAR2(30),
>cityVARCHAR2(20),
>state   CHAR(2),
>postal_code VARCHAR2(6));
> {code}
> Calcite complains in two places: OBJECT and VARCHAR2. 
> The following compiles fine:
> {code:sql}
> CREATE TYPE address_typ AS (
>street  VARCHAR(30),
>cityVARCHAR(20),
>state   CHAR(2),
>postal_code VARCHAR(6));
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CALCITE-5591) Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT functions (enabled in BigQuery library)

[Tanner Clary (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanner Clary resolved CALCITE-5591.
---
Fix Version/s: 1.36.0
   Resolution: Fixed

This umbrella issue is being resolved because all of the subtasks have been 
completed. You may find the commit hashes for the subtasks on their respective 
JIRA cases. Thanks to all of those who helped with reviews.

> Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT 
> functions (enabled in BigQuery library)
> 
>
> Key: CALCITE-5591
> URL: https://issues.apache.org/jira/browse/CALCITE-5591
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Dan Zou
>Assignee: Tanner Clary
>Priority: Major
> Fix For: 1.36.0
>
>
> Add support for SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE and 
> SAFE_NEGATE in BigQuery.
> Function description:
> * SAFE_ADD: Equivalent to the addition operator '+', but returns NULL if 
> overflow occurs.
> * SAFE_SUBTRACT: Equivalent to the subtraction operator '-', but returns NULL 
> if overflow occurs.
> * SAFE_MULTIPLY: Equivalent to the multiplication operator '*', but returns 
> NULL if overflow occurs.
> * SAFE_DIVIDE: Equivalent to the division operator '/ ', but returns NULL if 
> an error occurs, such as a division by zero error.
> * SAFE_NEGATE: Equivalent to the unary minus operator '-', but returns NULL 
> if overflow occurs.
> See more details in [BigQuery 
> Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#safe_divide]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (CALCITE-5591) Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT functions (enabled in BigQuery library)

[Tanner Clary (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanner Clary reassigned CALCITE-5591:
-

Assignee: Tanner Clary  (was: Dan Zou)

> Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT 
> functions (enabled in BigQuery library)
> 
>
> Key: CALCITE-5591
> URL: https://issues.apache.org/jira/browse/CALCITE-5591
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Dan Zou
>Assignee: Tanner Clary
>Priority: Major
>
> Add support for SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE and 
> SAFE_NEGATE in BigQuery.
> Function description:
> * SAFE_ADD: Equivalent to the addition operator '+', but returns NULL if 
> overflow occurs.
> * SAFE_SUBTRACT: Equivalent to the subtraction operator '-', but returns NULL 
> if overflow occurs.
> * SAFE_MULTIPLY: Equivalent to the multiplication operator '*', but returns 
> NULL if overflow occurs.
> * SAFE_DIVIDE: Equivalent to the division operator '/ ', but returns NULL if 
> an error occurs, such as a division by zero error.
> * SAFE_NEGATE: Equivalent to the unary minus operator '-', but returns NULL 
> if overflow occurs.
> See more details in [BigQuery 
> Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#safe_divide]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5591) Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT functions (enabled in BigQuery library)

[Tanner Clary (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanner Clary updated CALCITE-5591:
--
Summary: Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, 
SAFE_SUBTRACT functions (enabled in BigQuery library)  (was: Implement BigQuery 
functions SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE and SAFE_NEGATE)

> Add SAFE_ADD, SAFE_DIVIDE, SAFE_MULTIPLY, SAFE_NEGATE, SAFE_SUBTRACT 
> functions (enabled in BigQuery library)
> 
>
> Key: CALCITE-5591
> URL: https://issues.apache.org/jira/browse/CALCITE-5591
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Dan Zou
>Assignee: Dan Zou
>Priority: Major
>
> Add support for SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE and 
> SAFE_NEGATE in BigQuery.
> Function description:
> * SAFE_ADD: Equivalent to the addition operator '+', but returns NULL if 
> overflow occurs.
> * SAFE_SUBTRACT: Equivalent to the subtraction operator '-', but returns NULL 
> if overflow occurs.
> * SAFE_MULTIPLY: Equivalent to the multiplication operator '*', but returns 
> NULL if overflow occurs.
> * SAFE_DIVIDE: Equivalent to the division operator '/ ', but returns NULL if 
> an error occurs, such as a division by zero error.
> * SAFE_NEGATE: Equivalent to the unary minus operator '-', but returns NULL 
> if overflow occurs.
> See more details in [BigQuery 
> Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#safe_divide]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CALCITE-5933) Add SAFE_DIVIDE function (enabled in BigQuery library)

[Tanner Clary (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanner Clary resolved CALCITE-5933.
---
Fix Version/s: 1.36.0
   Resolution: Fixed

Merged via 
[b19f373|https://github.com/apache/calcite/commit/b19f373b41089077aaccd688db57a32901e19c3d],
 thanks for the review, [~oliverlee]!

> Add SAFE_DIVIDE function (enabled in BigQuery library)
> --
>
> Key: CALCITE-5933
> URL: https://issues.apache.org/jira/browse/CALCITE-5933
> Project: Calcite
>  Issue Type: Sub-task
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Subtask of [CALCITE-5591] which aims to implement all of BigQuery's safe 
> arithmetic functions, this task covers the implementation of SAFE_DIVIDE.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5884) Description of ARRAY_TO_STRING function is incomplete

[Mihai Budiu (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihai Budiu updated CALCITE-5884:
-
Fix Version/s: 1.36.0

> Description of ARRAY_TO_STRING function is incomplete
> -
>
> Key: CALCITE-5884
> URL: https://issues.apache.org/jira/browse/CALCITE-5884
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Trivial
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> This is the current definition of the function ARRAY_TO_STRING in 
> SqlLibraryOperators:
> {code:java}
>   /** The "ARRAY_TO_STRING(array, delimiter [, nullText ])" function. */
>   @LibraryOperator(libraries = {BIG_QUERY})
>   public static final SqlFunction ARRAY_TO_STRING =
>   SqlBasicFunction.create(SqlKind.ARRAY_TO_STRING,
>   ReturnTypes.VARCHAR_NULLABLE,
>   OperandTypes.STRING_ARRAY_CHARACTER_OPTIONAL_CHARACTER);
> {code}
> So the result is nullable if any of the arguments is nullable. However, the 
> nullability of the last argument does not influence the result nullabillity: 
> a NULL value for the third optional argument will not cause a NULL value to 
> be output.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5884) Description of ARRAY_TO_STRING function is incomplete

[Mihai Budiu (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762224#comment-17762224
 ] 

Mihai Budiu commented on CALCITE-5884:
--

Can someone please review this PR?


> Description of ARRAY_TO_STRING function is incomplete
> -
>
> Key: CALCITE-5884
> URL: https://issues.apache.org/jira/browse/CALCITE-5884
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Trivial
>  Labels: pull-request-available
>
> This is the current definition of the function ARRAY_TO_STRING in 
> SqlLibraryOperators:
> {code:java}
>   /** The "ARRAY_TO_STRING(array, delimiter [, nullText ])" function. */
>   @LibraryOperator(libraries = {BIG_QUERY})
>   public static final SqlFunction ARRAY_TO_STRING =
>   SqlBasicFunction.create(SqlKind.ARRAY_TO_STRING,
>   ReturnTypes.VARCHAR_NULLABLE,
>   OperandTypes.STRING_ARRAY_CHARACTER_OPTIONAL_CHARACTER);
> {code}
> So the result is nullable if any of the arguments is nullable. However, the 
> nullability of the last argument does not influence the result nullabillity: 
> a NULL value for the third optional argument will not cause a NULL value to 
> be output.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5905) Documentation for CREATE TYPE is incorrect

[Mihai Budiu (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihai Budiu updated CALCITE-5905:
-
Fix Version/s: 1.36.0

> Documentation for CREATE TYPE is incorrect
> --
>
> Key: CALCITE-5905
> URL: https://issues.apache.org/jira/browse/CALCITE-5905
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I have tried to run the example CREATE TYPE statements from this page 
> https://calcite.apache.org/docs/reference.html#declaring-objects-for-user-defined-types
> through the compiler:
> {code:sql}
> CREATE TYPE address_typ AS OBJECT (
>street  VARCHAR2(30),
>cityVARCHAR2(20),
>state   CHAR(2),
>postal_code VARCHAR2(6));
> {code}
> Calcite complains in two places: OBJECT and VARCHAR2. 
> The following compiles fine:
> {code:sql}
> CREATE TYPE address_typ AS (
>street  VARCHAR(30),
>cityVARCHAR(20),
>state   CHAR(2),
>postal_code VARCHAR(6));
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5905) Documentation for CREATE TYPE is incorrect

[Mihai Budiu (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762223#comment-17762223
 ] 

Mihai Budiu commented on CALCITE-5905:
--

Can someone please review the related PR?
I have asked already on github, but no one did.

> Documentation for CREATE TYPE is incorrect
> --
>
> Key: CALCITE-5905
> URL: https://issues.apache.org/jira/browse/CALCITE-5905
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>  Labels: pull-request-available
>
> I have tried to run the example CREATE TYPE statements from this page 
> https://calcite.apache.org/docs/reference.html#declaring-objects-for-user-defined-types
> through the compiler:
> {code:sql}
> CREATE TYPE address_typ AS OBJECT (
>street  VARCHAR2(30),
>cityVARCHAR2(20),
>state   CHAR(2),
>postal_code VARCHAR2(6));
> {code}
> Calcite complains in two places: OBJECT and VARCHAR2. 
> The following compiles fine:
> {code:sql}
> CREATE TYPE address_typ AS (
>street  VARCHAR(30),
>cityVARCHAR(20),
>state   CHAR(2),
>postal_code VARCHAR(6));
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)

[Jerin John (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerin John updated CALCITE-5979:

Description: Add support for [REGEXP_REPLACE 
|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
 function from BigQuery.  (was: Add support for 
[REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
 function from BigQuery.

*{{REGEXP_EXTRACT_ALL(value, regexp)}}*
Returns an array of all substrings of value that match the re2 regular 
expression, regexp. Returns an empty array if there is no match.

* If the regular expression contains a capturing group ((...)), and there is a 
match for that capturing group, that match is added to the results. If there 
are multiple matches for a capturing group, the last match is added to the 
results.)

> Add REGEXP_REPLACE function (enabled in BigQuery library)
> -
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
>  Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
>  Labels: pull-request-available
>
> Add support for [REGEXP_REPLACE 
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
>  function from BigQuery.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5978) Add REGEXP_INSTR function (enabled in BigQuery library)

[Jerin John (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerin John updated CALCITE-5978:

Description: Add support for [REGEXP_INSTR 
|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_instr]
 function from BigQuery.  (was: Add support for 
[REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
 function from BigQuery.

*{{REGEXP_EXTRACT_ALL(value, regexp)}}*
Returns an array of all substrings of value that match the re2 regular 
expression, regexp. Returns an empty array if there is no match.

* If the regular expression contains a capturing group ((...)), and there is a 
match for that capturing group, that match is added to the results. If there 
are multiple matches for a capturing group, the last match is added to the 
results.)

> Add REGEXP_INSTR function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5978
> URL: https://issues.apache.org/jira/browse/CALCITE-5978
> Project: Calcite
>  Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
>  Labels: pull-request-available
>
> Add support for [REGEXP_INSTR 
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_instr]
>  function from BigQuery.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)

[Jerin John (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerin John updated CALCITE-5979:

Fix Version/s: (was: 1.36.0)

> Add REGEXP_REPLACE function (enabled in BigQuery library)
> -
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
>  Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
>  Labels: pull-request-available
>
> Add support for 
> [REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
>  function from BigQuery.
> *{{REGEXP_EXTRACT_ALL(value, regexp)}}*
> Returns an array of all substrings of value that match the re2 regular 
> expression, regexp. Returns an empty array if there is no match.
> * If the regular expression contains a capturing group ((...)), and there is 
> a match for that capturing group, that match is added to the results. If 
> there are multiple matches for a capturing group, the last match is added to 
> the results.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5978) Add REGEXP_INSTR function (enabled in BigQuery library)

[Jerin John (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerin John updated CALCITE-5978:

Fix Version/s: (was: 1.36.0)

> Add REGEXP_INSTR function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-5978
> URL: https://issues.apache.org/jira/browse/CALCITE-5978
> Project: Calcite
>  Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
>  Labels: pull-request-available
>
> Add support for 
> [REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
>  function from BigQuery.
> *{{REGEXP_EXTRACT_ALL(value, regexp)}}*
> Returns an array of all substrings of value that match the re2 regular 
> expression, regexp. Returns an empty array if there is no match.
> * If the regular expression contains a capturing group ((...)), and there is 
> a match for that capturing group, that match is added to the results. If 
> there are multiple matches for a capturing group, the last match is added to 
> the results.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)

[Jerin John (Jira)]

Jerin John created CALCITE-5979:
---

 Summary: Add REGEXP_REPLACE function (enabled in BigQuery library)
 Key: CALCITE-5979
 URL: https://issues.apache.org/jira/browse/CALCITE-5979
 Project: Calcite
  Issue Type: Task
Reporter: Jerin John
Assignee: Jerin John
 Fix For: 1.36.0


Add support for 
[REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
 function from BigQuery.

*{{REGEXP_EXTRACT_ALL(value, regexp)}}*
Returns an array of all substrings of value that match the re2 regular 
expression, regexp. Returns an empty array if there is no match.

* If the regular expression contains a capturing group ((...)), and there is a 
match for that capturing group, that match is added to the results. If there 
are multiple matches for a capturing group, the last match is added to the 
results.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5978) Add REGEXP_INSTR function (enabled in BigQuery library)

[Jerin John (Jira)]

Jerin John created CALCITE-5978:
---

 Summary: Add REGEXP_INSTR function (enabled in BigQuery library)
 Key: CALCITE-5978
 URL: https://issues.apache.org/jira/browse/CALCITE-5978
 Project: Calcite
  Issue Type: Task
Reporter: Jerin John
Assignee: Jerin John
 Fix For: 1.36.0


Add support for 
[REGEXP_EXTRACT_ALL|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_extract_all]
 function from BigQuery.

*{{REGEXP_EXTRACT_ALL(value, regexp)}}*
Returns an array of all substrings of value that match the re2 regular 
expression, regexp. Returns an empty array if there is no match.

* If the regular expression contains a capturing group ((...)), and there is a 
match for that capturing group, that match is added to the results. If there 
are multiple matches for a capturing group, the last match is added to the 
results.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5967) UnsupportedOperationException while implementing a call that requires a special collator

[Julian Hyde (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762213#comment-17762213
 ] 

Julian Hyde commented on CALCITE-5967:
--

Only one request. Improve the documentation of the test. As it stands it is 
very difficult to see what is being tested, i.e. what is the 'hard thing' that 
makes this test different from other tests. In tests, code doesn't always speak 
for itself.

In {{{}RexImpTable{}}}, can you use {{{}FlatLists.append(argValueList, 
fieldComparator){}}}. Functional is better.

> UnsupportedOperationException while implementing a call that requires a 
> special collator
> 
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while 
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see 
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
>  introduced this apparently innocuous change in 
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the 
> old one returns an {{ArrayList}} (where we can add new elements); whereas the 
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that 
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list 
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
>   ...
>   optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
>   final Expression callValue =
>   implementSafe(translator, call, optimizedArgValueList);
>   ...
> }
> @Override Expression implementSafe(...) {
>   ...
>   final Expression fieldComparator =
>   generateCollatorExpression(relDataType0.getCollation());
>   if (fieldComparator != null) {
> argValueList.add(fieldComparator);  // <--- 
> UnsupportedOperationException!
>   }
>   ...
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5977) RexLiteral returns the same value for TIMESTAMP and TIMESTAMP_WITH_LOCAL_TIME_ZONE

[Julian Hyde (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762149#comment-17762149
 ] 

Julian Hyde commented on CALCITE-5977:
--

Only if Calcite considers those queries valid.

> RexLiteral returns the same value for TIMESTAMP and 
> TIMESTAMP_WITH_LOCAL_TIME_ZONE
> --
>
> Key: CALCITE-5977
> URL: https://issues.apache.org/jira/browse/CALCITE-5977
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Ruben Q L
>Priority: Major
>
> Perhaps I'm missing something, but this seems odd to me.
> If we want to get the value in Long format (i.e. milliseconds since 
> 1970-01-01 00:00:00) of a TIMESTAMP / TIMESTAMP_WITH_LOCAL_TIME_ZONE 
> RexLiteral, their code is exactly the same (even if they are in different 
> "case" blocks):
> {code}
>   public @Nullable Object getValue2() {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   return getValueAs(Long.class);
> ...
>   }
>   public  @Nullable T getValueAs(Class clazz) {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
>   ...
>   break;
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
> ...
> {code}
> In case of a TIMESTAMP_WITH_LOCAL_TIME_ZONE, shouldn't this code include some 
> extra processing to "shift" the value with the proper offset / daylight 
> savings?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CALCITE-5821) Add FORMAT_NUMBER function (enabled in Hive and Spark library)

[Tanner Clary (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tanner Clary resolved CALCITE-5821.
---
Fix Version/s: 1.36.0
   Resolution: Fixed

Merged via 
[aa5397b|https://github.com/apache/calcite/commit/aa5397bed42313865d3a43908427ad5f12b27ef3],
 thanks for the fix, [~Runking]!

> Add FORMAT_NUMBER function (enabled in Hive and Spark library)
> --
>
> Key: CALCITE-5821
> URL: https://issues.apache.org/jira/browse/CALCITE-5821
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Affects Versions: 1.34.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add FORMAT_NUMBER function (enabled in Hive and Spark library):
> FORMAT_NUMBER(expr1, expr2) - Formats the number {{expr1}} like 
> '#,###,###.##', rounded to {{expr2}} decimal places. If {{expr2}} is 0, the 
> result has no decimal point or fractional part. {{expr2}} also accept a user 
> specified format. This is supposed to function like MySQL's FORMAT.
> See more details in 
> [Hive|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf#LanguageManualUDF-StringFunctions]
>  and 
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#format_number] 
> doc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5977) RexLiteral returns the same value for TIMESTAMP and TIMESTAMP_WITH_LOCAL_TIME_ZONE

[Ruben Q L (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762129#comment-17762129
 ] 

Ruben Q L commented on CALCITE-5977:


Thanks for the feedback [~julianhyde].

But then, if I am not mistaken, that would mean that if we run these two 
queries in Calcite:
{code:sql}
SELECT * FROM myTable t WHERE t.lastUpdate > TIMESTAMP'2023-08-28 09:56:54'

SELECT * FROM myTable t WHERE t.lastUpdate > TIMESTAMP WITH LOCAL TIME 
ZONE'2023-08-28 09:56:54'
{code}

The dynamic code that will be generated to produce the query result with 
Enumerable convention will be exactly the same, right? Is that correct?



> RexLiteral returns the same value for TIMESTAMP and 
> TIMESTAMP_WITH_LOCAL_TIME_ZONE
> --
>
> Key: CALCITE-5977
> URL: https://issues.apache.org/jira/browse/CALCITE-5977
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Ruben Q L
>Priority: Major
>
> Perhaps I'm missing something, but this seems odd to me.
> If we want to get the value in Long format (i.e. milliseconds since 
> 1970-01-01 00:00:00) of a TIMESTAMP / TIMESTAMP_WITH_LOCAL_TIME_ZONE 
> RexLiteral, their code is exactly the same (even if they are in different 
> "case" blocks):
> {code}
>   public @Nullable Object getValue2() {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   return getValueAs(Long.class);
> ...
>   }
>   public  @Nullable T getValueAs(Class clazz) {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
>   ...
>   break;
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
> ...
> {code}
> In case of a TIMESTAMP_WITH_LOCAL_TIME_ZONE, shouldn't this code include some 
> extra processing to "shift" the value with the proper offset / daylight 
> savings?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5977) RexLiteral returns the same value for TIMESTAMP and TIMESTAMP_WITH_LOCAL_TIME_ZONE

[Julian Hyde (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762126#comment-17762126
 ] 

Julian Hyde commented on CALCITE-5977:
--

I don’t think there’s a problem. These methods are for “compiler engineers” who 
can be trusted to use the raw, untyped value. The guardrails that prevent, say, 
converting a TIMESTAMP to a TIMESTAMP WITH LOCAL TIME ZONE without providing a 
time zone exist in our SQL language but don’t exist here. 

> RexLiteral returns the same value for TIMESTAMP and 
> TIMESTAMP_WITH_LOCAL_TIME_ZONE
> --
>
> Key: CALCITE-5977
> URL: https://issues.apache.org/jira/browse/CALCITE-5977
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Ruben Q L
>Priority: Major
>
> Perhaps I'm missing something, but this seems odd to me.
> If we want to get the value in Long format (i.e. milliseconds since 
> 1970-01-01 00:00:00) of a TIMESTAMP / TIMESTAMP_WITH_LOCAL_TIME_ZONE 
> RexLiteral, their code is exactly the same (even if they are in different 
> "case" blocks):
> {code}
>   public @Nullable Object getValue2() {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   return getValueAs(Long.class);
> ...
>   }
>   public  @Nullable T getValueAs(Class clazz) {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
>   ...
>   break;
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
>   if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
>   }
> ...
> {code}
> In case of a TIMESTAMP_WITH_LOCAL_TIME_ZONE, shouldn't this code include some 
> extra processing to "shift" the value with the proper offset / daylight 
> savings?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5975) percentile_cont function throws UnsupportedOperationException

[Tanner Clary (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762124#comment-17762124
 ] 

Tanner Clary commented on CALCITE-5975:
---

It looks like that method always throws an {{UnsupportedOperationException}}. I 
also see that {{PERCENTILE_DISC}} has an override in {{Aggregate.java}}. 
Perhaps adding a similar override for {{PERCENTILE_CONT}} (or allowing it to 
use the same as {{PERCENTILE_DISC}}, I am not sure about the specifics}}) could 
help fix the problem. I have done some work on these functions so if you open a 
fix let me know, I would be happy to help review.

> percentile_cont function throws UnsupportedOperationException
> -
>
> Key: CALCITE-5975
> URL: https://issues.apache.org/jira/browse/CALCITE-5975
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: wqn
>Priority: Major
>
> execute a sql like
> {code:java}
> SELECT  percentile_cont(0.0005) within group (ORDER BY aa  DESC)   from  
> table{code}
> it throws UnsupportedOperationException
> {code:java}
> Caused by: java.lang.UnsupportedOperationException: null        at 
> org.apache.calcite.sql.SqlOperatorBinding.getCollationType(SqlOperatorBinding.java:244)
>         at 
> org.apache.calcite.sql.type.ReturnTypes.lambda$static$25(ReturnTypes.java:1285)
>         at 
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:533)      
>   at org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198) 
>        at 
> org.apache.calcite.tools.RelBuilder$AggCallImpl.aggregateCall(RelBuilder.java:4173)
>         at 
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2424)        
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2348)        
> at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimFields(RelFieldTrimmer.java:1102)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)        
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>        at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)        at 
> org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:532)        at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.dispatchTrimFields(RelFieldTrimmer.java:283)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimChild(RelFieldTrimmer.java:225)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimFields(RelFieldTrimmer.java:494)
>         at sun.reflect.GeneratedMethodAccessor1005.invoke(Unknown Source)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:532)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.dispatchTrimFields(RelFieldTrimmer.java:283)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimChild(RelFieldTrimmer.java:225)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimFields(RelFieldTrimmer.java:824)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:532)
>         at 
> org.apache.calcite.sql2rel.RelFieldTrimmer.dispatchTrimFields(RelFieldTrimmer.java:283)
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5977) RexLiteral returns the same value for TIMESTAMP and TIMESTAMP_WITH_LOCAL_TIME_ZONE

[Ruben Q L (Jira)]

Ruben Q L created CALCITE-5977:
--

 Summary: RexLiteral returns the same value for TIMESTAMP and 
TIMESTAMP_WITH_LOCAL_TIME_ZONE
 Key: CALCITE-5977
 URL: https://issues.apache.org/jira/browse/CALCITE-5977
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: Ruben Q L


Perhaps I'm missing something, but this seems odd to me.

If we want to get the value in Long format (i.e. milliseconds since 1970-01-01 
00:00:00) of a TIMESTAMP / TIMESTAMP_WITH_LOCAL_TIME_ZONE RexLiteral, their 
code is exactly the same (even if they are in different "case" blocks):

{code}
  public @Nullable Object getValue2() {
...
switch (typeName) {
...
case TIMESTAMP:
case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
  return getValueAs(Long.class);
...
  }

  public  @Nullable T getValueAs(Class clazz) {
...
switch (typeName) {
...
case TIMESTAMP:
  if (clazz == Long.class) {
// Milliseconds since 1970-01-01 00:00:00
return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
  }
  ...
  break;
case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
  if (clazz == Long.class) {
// Milliseconds since 1970-01-01 00:00:00
return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
  }
...
{code}

In case of a TIMESTAMP_WITH_LOCAL_TIME_ZONE, shouldn't this code include some 
extra processing to "shift" the value with the proper offset / daylight savings?




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression

[Stamatis Zampetakis (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis updated CALCITE-5957:
-
Fix Version/s: avatica-1.24.0

> Valid DATE '1945-2-2' is not accepted due to regression
> ---
>
> Key: CALCITE-5957
> URL: https://issues.apache.org/jira/browse/CALCITE-5957
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Evgeny Stanilovsky
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: avatica-1.24.0
>
> Attachments: image-2023-08-27-19-09-33-284.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result 
> check of `testCastStringToDateTime`, we find that Calcite accepted DATE 
> '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression 
> that we need to fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression

[Stamatis Zampetakis (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis updated CALCITE-5957:
-
Priority: Blocker  (was: Major)

> Valid DATE '1945-2-2' is not accepted due to regression
> ---
>
> Key: CALCITE-5957
> URL: https://issues.apache.org/jira/browse/CALCITE-5957
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Evgeny Stanilovsky
>Priority: Blocker
>  Labels: pull-request-available
> Attachments: image-2023-08-27-19-09-33-284.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result 
> check of `testCastStringToDateTime`, we find that Calcite accepted DATE 
> '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression 
> that we need to fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-5860) Decimal type conversion missing scale

[Stamatis Zampetakis (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762063#comment-17762063
 ] 

Stamatis Zampetakis commented on CALCITE-5860:
--

Hey [~pfzhan], I left some additional comments in the PR roughly 2 weeks ago. 
Did you have a chance to look into them?

> Decimal type conversion missing scale
> -
>
> Key: CALCITE-5860
> URL: https://issues.apache.org/jira/browse/CALCITE-5860
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.34.0
>Reporter: Guoliang Sun
>Assignee: pengfei.zhan
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Take the following SQL as an example
> {code:sql}
> SELECT CAST(((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)) * SQRT(3.0) {code}
> The result of the SQL calculation should be {*}SQRT(3.0){*}.However, the 
> actual result is {*}2.0{*}, which is not meet expectations.
>  
> The following is the code generated by Janino
> {code:java}
> public Object[] apply(Object root0) {
>   final java.math.BigDecimal literal_value = new java.math.BigDecimal(
>     "2.0");
>   final java.math.BigDecimal literal_value0 = new java.math.BigDecimal(
>     "3.0");
>   final java.math.BigDecimal literal_value1 = new java.math.BigDecimal(
>     "0.5");
>   final double method_name_call_value = 
> org.apache.calcite.runtime.SqlFunctions.power(literal_value0, literal_value1);
>   final java.math.BigDecimal cast_value = new java.math.BigDecimal(
>     literal_value.doubleValue() / method_name_call_value);
>   return new Object[] {
>       cast_value == null ? 0.0D : cast_value.doubleValue() * 
> method_name_call_value};
> } {code}
> We can see *((2.0) / SQRT(3.0)) AS DECIMAL(18, 0)* lost the scale.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals the derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5948:
-
Summary: Explicit casting should be made if the type of an element in 
ARRAY/MAP not equals the derived component type  (was: Explicit casting should 
be made if the type of an element in ARRAY/MAP not equals with the derived 
component type)

> Explicit casting should be made if the type of an element in ARRAY/MAP not 
> equals the derived component type
> 
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>  Labels: pull-request-available
>
> First, we need to reach a consensus to allow types of the same family to 
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the 
> LeastRestrictiveType is Integer). However, this function validate success in 
> calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
> java.lang.Integer
>     at 
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
>     at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
>     at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
>     at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
>     at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
>     at 
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
>     at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
>     at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
>     at 
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
>     at 
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
>  {code}
>  
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw 
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not; 
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must 
> be of the same type]
>   at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)  
> at 
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
>  {code}
>  
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
>   public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
>   }
>   @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
>   }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
>   public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
>   }
>   @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
>      --> we need explicit cast here   
>      return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
>   }
> }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Description: 
If we run the expression below in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}
{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Description: 
If we run the expression below in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}
{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals with derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Summary: The ArrayPrepend/ArrayAppend/ArrayInsert function should make 
explicit casting when element type not equals with derived component type  
(was: The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit 
casting when element type not equals derived component type)

> The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit 
> casting when element type not equals with derived component type
> ---
>
> Key: CALCITE-5976
> URL: https://issues.apache.org/jira/browse/CALCITE-5976
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> array_prepend(array[1], cast(2 as tinyint));
> array_append(array[1], cast(2 as tinyint)) {code}
> {noformat}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
> java.lang.Integer (java.lang.Byte and java.lang.Integer are in module 
> java.base of loader 'bootstrap')
>  
> at 
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at 
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at 
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at 
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
> at 
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
> at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
> at 
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
> at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
> at 
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
> at 
> org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Summary: The ArrayPrepend/ArrayAppend/ArrayInsert function should make 
explicit casting when element type not equals derived component type  (was: The 
ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when 
element type not equals with derived component type)

> The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit 
> casting when element type not equals derived component type
> --
>
> Key: CALCITE-5976
> URL: https://issues.apache.org/jira/browse/CALCITE-5976
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> array_prepend(array[1], cast(2 as tinyint));
> array_append(array[1], cast(2 as tinyint)) {code}
> {noformat}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
> java.lang.Integer (java.lang.Byte and java.lang.Integer are in module 
> java.base of loader 'bootstrap')
>  
> at 
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at 
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at 
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at 
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at 
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
> at 
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
> at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
> at 
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
> at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
> at 
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
> at 
> org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at 
> 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Description: 
If we run the expression below in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}
{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Environment: (was: If we run them in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}

{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at 

[jira] [Created] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

Ran Tao created CALCITE-5976:


 Summary: The ArrayPrepend/ArrayAppend/ArrayInsert function should 
make explicit casting when element type not equals derived component type
 Key: CALCITE-5976
 URL: https://issues.apache.org/jira/browse/CALCITE-5976
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.35.0
 Environment: If we run them in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}

{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 

[jira] [Updated] (CALCITE-5976) The ArrayPrepend/ArrayAppend/ArrayInsert function should make explicit casting when element type not equals derived component type

[Ran Tao (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Tao updated CALCITE-5976:
-
Description: 
If we run them in calcite, it will cause exception:
{code:java}
array_prepend(array[1], cast(2 as tinyint));
array_append(array[1], cast(2 as tinyint)) {code}
{noformat}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
java.lang.Integer (java.lang.Byte and java.lang.Integer are in module java.base 
of loader 'bootstrap')
 
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at 
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at 
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at 
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at 
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
at 
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12785)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at 
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at 
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at 
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at 
org.apache.calcite.test.SqlOperatorTest.testArrayPrependFunc(SqlOperatorTest.java:6077)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at 

[jira] [Comment Edited] (CALCITE-5968) Provide an interface for RexExecutable to decouple janino runtime binding

[Wenzhuang Zhu (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761238#comment-17761238
 ] 

Wenzhuang Zhu edited comment on CALCITE-5968 at 9/5/23 8:39 AM:


To [~libenchao] 

I read the code of RexImplicationChecker. In that situation, DataContext is a 
better way to change a RexInputRef's input data. Otherwise, 
RexImplicationChecker.isSatisfiable needs make a new RexCall to call 
RexExecutor.reduce .

To [~julianhyde] 
 * fixed
 * done
 * public class is better for user to choose reuse it's code or not. 
RexExecutorImpl is also a public class(and other Rex*Impl classes). So, I keep 
the 'public class'.
 * I'm not sure decouple linq4j function class is an improvement or not. 
Interfaces RexExecutor/RexExecutable hide the implementation details. So, it 
works for JNI executor users.
 * I added a UserExecutor/UserExecutable test in 
[https://github.com/apache/calcite/pull/3404/files#diff-788b8a6d9613c5263347de845baf5ee6d920f784462419efb2b2e84a342b9d51.]
  It tests on interface level without moving the path of RexExecutorTest.

Please review the PR([https://github.com/apache/calcite/pull/3404)] or give 
more comments. Thanks. 


was (Author: JIRAUSER295386):
To [~libenchao] 

I read the code of RexImplicationChecker. In that situation, DataContext is a 
better way to change a RexInputRef's input data. Otherwise, 
RexImplicationChecker.isSatisfiable needs make a new RexCall to call 
RexExecutor.reduce .

To [~julianhyde] 
 * fixed
 * done
 * public class is better for user to choose reuse it's code or not. 
RexExecutorImpl is also a public class(and other Rex*Impl classes). So, I keep 
the 'public class'.
 * I'm not sure decouple linq4j function class is an improvement or not. 
Interfaces RexExecutor/RexExecutable hide the implementation details. So, it 
works for JNI executor users.
 * I added a UserExecutor/UserExecutable test in 
[https://github.com/apache/calcite/pull/3404/files#diff-788b8a6d9613c5263347de845baf5ee6d920f784462419efb2b2e84a342b9d51.]
  It tests on interface level without moving the path of RexExecutorTest.

Please review the PR([https://github.com/apache/calcite/pull/3404)] or give 
more comments. Thanks. 

> Provide an interface for RexExecutable to decouple janino runtime binding
> -
>
> Key: CALCITE-5968
> URL: https://issues.apache.org/jira/browse/CALCITE-5968
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Wenzhuang Zhu
>Assignee: Wenzhuang Zhu
>Priority: Minor
>  Labels: pull-request-available
>
> Provide an interface for RexExecutable to decouple janino runtime binding.
> Users may want to use a different runtime implementation({_}e.g.{_} JNI) .



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CALCITE-5953) AggregateCaseToFilterRule may make inaccurate SUM transformation

[Zoltan Haindrich (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zoltan Haindrich resolved CALCITE-5953.
---
Fix Version/s: 1.36.0
   Resolution: Fixed

Fixed in 
[05787a67|https://github.com/apache/calcite/commit/05787a6793d5393ee05c99182e05823d12edab12]


> AggregateCaseToFilterRule may make inaccurate SUM transformation
> 
>
> Key: CALCITE-5953
> URL: https://issues.apache.org/jira/browse/CALCITE-5953
> Project: Calcite
>  Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.36.0
>
>
> consider: {{sum(case when x = 1 then 2 else 0 end) as b}}
> notice that this expression may only be null if there are no rows in the table
> {{AggregateCaseToFilterRule}} rewrites the above expression to {{sum(1) 
> filter (where x=2)}} which broadens when it could be `null` to when there are 
> no matches to the filter
> * *A* is *0* correctly in this case; but I think it will be still *0* in case 
> there are 0 input rows
> * The result for *B* supposed to be *0* but since there are no matches by the 
> filter it becomes *null*
> * *C* is not touched
> {code}
> # Convert CASE to FILTER without matches
> select  sum(case when x = 1 then 1 else 0 end) as a,
> sum(case when x = 1 then 2 else 0 end) as b,
> sum(case when x = 1 then 3 else -1 end) as c
> from (values 0, null, 0, 2) as t(x);
> +---+---++
> | A | B | C  |
> +---+---++
> | 0 | 0 | -4 |
> +---+---++
> (1 row)
> !ok
> EnumerableCalc(expr#0..2=[{inputs}], expr#3=[CAST($t0):INTEGER], A=[$t3], 
> B=[$t1], C=[$t2])
>   EnumerableAggregate(group=[{}], A=[COUNT() FILTER $1], B=[SUM($2) FILTER 
> $3], C=[SUM($0)])
> EnumerableCalc(expr#0=[{inputs}], expr#1=[1], expr#2=[=($t0, $t1)], 
> expr#3=[3], expr#4=[-1], expr#5=[CASE($t2, $t3, $t4)], expr#6=[IS TRUE($t2)], 
> expr#7=[2], $f2=[$t5], $f3=[$t6], $f4=[$t7], $f5=[$t6])
>   EnumerableValues(tuples=[[{ 0 }, { null }, { 0 }, { 2 }]])
> !plan
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)