[jira] [Commented] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767827#comment-17767827
]
Wenrui Meng commented on CALCITE-6007:
--
[~julianhyde] Do you agree with what I proposed to add alias EXPR$0 for CTE
subquery? Or you are asking where the EXPR$0 is generated. It's generated in
the registerFrom function where it derive the alias as needed.
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767826#comment-17767826 ] Evgeny Stanilovsky commented on CALCITE-5957: - '900-01-01' should be accepted and '9-01-01' too ? I think we need to move according to sql standard. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Priority: Blocker > Fix For: avatica-1.24.0 > > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
[
https://issues.apache.org/jira/browse/CALCITE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767768#comment-17767768
]
Julian Hyde commented on CALCITE-6020:
--
{{SUM0}} stores less information than {{SUM}}. Therefore there are situations
where {{SUM0}} is easier to compute and still provides the needed data. Summary
tables are one example.
If you need {{SUM}} you can compute it from {{SUM0}} and {{COUNT}}: {{SUM(x)
=== CASE COUNT(x) WHEN 0 THEN NULL ELSE SUM0(x)}}
I can't make the claim that SUM0 is definitely needed anywhere. However I do
claim that it is a better primitive than SUM, and we should be embracing the
best primitives we can find.
> SqlToRelConverter should not replace windowed SUM with equivalent expression
> using SUM0
> ---
>
> Key: CALCITE-6020
> URL: https://issues.apache.org/jira/browse/CALCITE-6020
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> {{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
> This might have been needed at some point in the past - but I think it will
> be better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the
> system that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it
> - as see
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
[
https://issues.apache.org/jira/browse/CALCITE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767768#comment-17767768
]
Julian Hyde edited comment on CALCITE-6020 at 9/22/23 1:12 AM:
---
{{SUM0}} stores less information than {{SUM}}. Therefore there are situations
where {{SUM0}} is easier to compute and still provides the needed data. Summary
tables are one example.
If you need {{SUM}} you can compute it from {{SUM0}} and {{COUNT}}: {{SUM\(x)
=== CASE COUNT\(x) WHEN 0 THEN NULL ELSE SUM0\(x)}}
I can't make the claim that SUM0 is definitely needed anywhere. However I do
claim that it is a better primitive than SUM, and we should be embracing the
best primitives we can find.
was (Author: julianhyde):
{{SUM0}} stores less information than {{SUM}}. Therefore there are situations
where {{SUM0}} is easier to compute and still provides the needed data. Summary
tables are one example.
If you need {{SUM}} you can compute it from {{SUM0}} and {{COUNT}}: {{SUM(x)
=== CASE COUNT(x) WHEN 0 THEN NULL ELSE SUM0(x)}}
I can't make the claim that SUM0 is definitely needed anywhere. However I do
claim that it is a better primitive than SUM, and we should be embracing the
best primitives we can find.
> SqlToRelConverter should not replace windowed SUM with equivalent expression
> using SUM0
> ---
>
> Key: CALCITE-6020
> URL: https://issues.apache.org/jira/browse/CALCITE-6020
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> {{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
> This might have been needed at some point in the past - but I think it will
> be better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the
> system that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it
> - as see
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767767#comment-17767767
]
Julian Hyde commented on CALCITE-6021:
--
Note that the {{CURRENT_TIMESTAMP}}, {{LOCAL_TIMESTAMP}} functions are
implemented more like variables than functions. This should be similar (or
perhaps expand to existing functions).
The return type of {{CURRENT_TIMESTAMP}} may be inconsistent with the SQL
standard. If so please devise a fix.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767766#comment-17767766
]
Julian Hyde commented on CALCITE-6007:
--
Good; and now find out how the "EXPR$0" alias is assigned.
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5978) Add REGEXP_INSTR function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767728#comment-17767728
]
Jerin John commented on CALCITE-5978:
-
Thanks for the feedback [~julianhyde], definitely agree and will keep in mind
for future changes.
I think the Github username issue would've been inconsistent between a commit I
made from IDE UI v/s cmdline, apologies for that confusion.
I understand the lack of clarity with that helper function, I'll update the
naming and javadoc to make the functionality more explicit alongside the next
commit.
> 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
> Fix For: 1.36.0
>
>
> Add support for [REGEXP_INSTR
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_instr]
> function from BigQuery.
> *{{REGEXP_INSTR(string, regexp [, position [, occurrence [,
> occurrence_position]]])}}*
> Returns the lowest 1-based position of the substring in {{string}} that
> matches the {{{}regexp{}}}, Returns 0 if there is no match
> * If {{position}} is specified, the search starts at this position in
> {{{}string{}}}, otherwise it starts at the beginning of {{{}string{}}}.
> * If {{occurrence}} is specified, the search returns index for the specific
> occurrence of the {{regexp}} in value, otherwise returns the first match.
> * If {{occurrence_position}} is specified as 1, returns the end index of
> substring + 1 (default 0 returns start index of match)
> Example:
> {{SELECT REGEXP_INSTR("abcadcabcaecghi", "adc") as result;}}
> |result|
> |4|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary updated CALCITE-6021:
--
Description:
Calcite supports parsing and validation for the CURRENT_DATETIME function
according to CALCITE-4297 . However a native implementation was never added.
The docs for the function may be found here:
https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
An example:
{{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
{{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
was:
Calcite supports parsing and validation for the CURRENT_DATETIME function
according to CALCITE-4297 . However a native implementation was never added.
The docs for the function may be found here:
https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
An example:
{{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
{{DATETIME}} (a Calcite TIMESTAMP_WITH_LOCAL_TIME_ZONE). There is an optional
time zone argument.
> Add CURRENT_DATETIME function (enabled in BigQuery library)
> ---
>
> Key: CALCITE-6021
> URL: https://issues.apache.org/jira/browse/CALCITE-6021
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Priority: Major
>
> Calcite supports parsing and validation for the CURRENT_DATETIME function
> according to CALCITE-4297 . However a native implementation was never added.
> The docs for the function may be found here:
>
> https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
> An example:
> {{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
> {{DATETIME}} (a Calcite TIMESTAMP). There is an optional time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6007) CTE as subquery without alias doesn't have correct alias setup
[
https://issues.apache.org/jira/browse/CALCITE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767725#comment-17767725
]
Wenrui Meng commented on CALCITE-6007:
--
The example you gave above will generate the following SQL statement when it's
unparsed.
{code:java}
select EXPR$0.a, EXPR$0.b
from (
select 1 as a, 2 as b) AS EXPR$0
where EXPR$0.a is not null
{code}
> CTE as subquery without alias doesn't have correct alias setup
> --
>
> Key: CALCITE-6007
> URL: https://issues.apache.org/jira/browse/CALCITE-6007
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Wenrui Meng
>Priority: Major
>
> {code:java}
> SELECT
> a,
> b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> *
> FROM
> sub)
> WHERE
> a IS NOT null
> {code}
> It will generate the following SQL statement after validation
> {code:java}
> SELECT
> EXPR$0.a,
> EXPR$0.b
> FROM (
> WITH
> sub AS (
> SELECT
> 1 AS a,
> 2 AS b)
> SELECT
> sub.a AS a, sub.b AS b
> FROM
> sub)
> WHERE
> EXPR$0.a IS NOT null
> {code}
> The validated SQL become invalid since there is no EXPR$0 alias append for
> the SqlWith sub query but used in the expression outside.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6021) Add CURRENT_DATETIME function (enabled in BigQuery library)
Tanner Clary created CALCITE-6021:
-
Summary: Add CURRENT_DATETIME function (enabled in BigQuery
library)
Key: CALCITE-6021
URL: https://issues.apache.org/jira/browse/CALCITE-6021
Project: Calcite
Issue Type: Bug
Reporter: Tanner Clary
Calcite supports parsing and validation for the CURRENT_DATETIME function
according to CALCITE-4297 . However a native implementation was never added.
The docs for the function may be found here:
https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#current_datetime
An example:
{{SELECT CURRENT_DATETIME([timezone])}} should return the current time as a
{{DATETIME}} (a Calcite TIMESTAMP_WITH_LOCAL_TIME_ZONE). There is an optional
time zone argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767667#comment-17767667
]
Julian Hyde commented on CALCITE-5955:
--
I see that {{allowsFraming}} is already defined in {{SqlOperator}}. Adding it
to {{SqlBasicAggFunction}} makes sense. Maybe it would even allow us to
obsolete {{SqlLeadLagAggFunction}} and {{SqlRankFunction}}.
i am worried that we are on a path to treating {{PERCENTILE_CONT2}} (our
version of percentile for BQ) as it if really is a window function. I prefer to
think of it as percentile aggregate function that happens to use {{OVER}} as
its syntax. Would it be sufficient to change the unparse function, and treat
functions with {{isPercentile() = true}} differently when the target dialect is
BQ?
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767660#comment-17767660
]
Julian Hyde commented on CALCITE-5955:
--
Can you define in the doc what you mean by 'allows framing'? Give examples of
functions that do and do not allow framing.
If someone was to use a BigQuery percentile function and unparse it in a
non-BigQuery dialect, what would happen?
If someone uses a BigQuery percentile function in a query (using 'OVER'
syntax), does it become an aggregate query? (Recall that in an aggregate query
I cannot reference columns that are not being grouped.)
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5955:
Labels: pull-request-available (was: )
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767647#comment-17767647
]
Tanner Clary commented on CALCITE-5955:
---
Hey [~julianhyde], my main problem was with the unparsing. For the example
query, I was imagining that text getting parsed, converted to a rel tree, and
then later being unparsed. I have a commit which takes advantage of the
{{allowsFraming}} method offered by {{SqlOperator}} to patch this, I will be
opening a PR shortly and would appreciate a review.
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5955) BigQuery PERCENTILE functions are unparsed incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary updated CALCITE-5955:
--
Summary: BigQuery PERCENTILE functions are unparsed incorrectly (was:
Non-aggregate window functions incorrectly contain window frame clause for
BigQuery)
> BigQuery PERCENTILE functions are unparsed incorrectly
> --
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5984) Cannot fully disable trimming unused fields using Calcite configs
[
https://issues.apache.org/jira/browse/CALCITE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766323#comment-17766323
]
Wegdan Ghazi edited comment on CALCITE-5984 at 9/21/23 2:04 PM:
[~julianhyde] Thank you Julian for the response :) Currently working on it.
A follow up question if you can,
What's the reason for the trimming being executed twice; in points 1 and 2 as
explained in the description?
was (Author: JIRAUSER302153):
[~julianhyde] Thank you Julian for the response :) Currently working on it.
A follow up question if you man,
What's the reason for the trimming being executed twice; in points 1 and 2 as
explained in the description?
> Cannot fully disable trimming unused fields using Calcite configs
> -
>
> Key: CALCITE-5984
> URL: https://issues.apache.org/jira/browse/CALCITE-5984
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Wegdan Ghazi
>Priority: Major
> Labels: pull-request-available
>
> In Prepare#prepareSql there are 2 instances of trimming unused fields
> 1.
> [Prepare#trimUnusedFields|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L375]
> called
> [here|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L297]
>
> {code:java}
> // Trim unused fields.
> root = trimUnusedFields(root); {code}
> 2.
> {color:#172b4d}[TrimFieldsProgram|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/tools/Programs.java#L369]{color}
> called
> [here|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L312]
> within
> {code:java}
> root = optimize(root, getMaterializations(), getLattices());
> {code}
> I want to turn of the field trimming due to a personalisation I'm
> implementing to scan a specific API, which I would think is possible using
> [SqlConverter.Config|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6085C20-L6085C26]
> I attempted to disable the trimming using hooks [PROGRAM,
> SQL2REL_CONVERTER_CONFIG_BUILDER], which succeeded to remove the trimming
> program, yet on
> [Prepare#trimUnusedFields|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L375]
> {code:java}
> // code placehprotected RelRoot trimUnusedFields(RelRoot root) {
> final SqlToRelConverter.Config config = SqlToRelConverter.config()
> .withTrimUnusedFields(shouldTrim(root.rel))
> .withExpand(THREAD_EXPAND.get())
>
> .withInSubQueryThreshold(castNonNull(THREAD_INSUBQUERY_THRESHOLD.get()));
> final SqlToRelConverter converter =
> getSqlToRelConverter(getSqlValidator(), catalogReader, config);
> final boolean ordered = !root.collation.getFieldCollations().isEmpty();
> final boolean dml = SqlKind.DML.contains(root.kind);
> return root.withRel(converter.trimUnusedFields(dml || ordered, root.rel));
> }
> {code}
> The config passed (and edited by the hook) gets overwritten and only
> _shouldTrim(root.rel)_ can enable/disable trimming, I would expect this to
> happen iff the config _withTrimUnusedFields_ is only set to {_}true{_}.
> Is this the intended behaviour? Any help is appreciated, thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
[
https://issues.apache.org/jira/browse/CALCITE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6020:
Labels: pull-request-available (was: )
> SqlToRelConverter should not replace windowed SUM with equivalent expression
> using SUM0
> ---
>
> Key: CALCITE-6020
> URL: https://issues.apache.org/jira/browse/CALCITE-6020
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> {{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
> This might have been needed at some point in the past - but I think it will
> be better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the
> system that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it
> - as see
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
[
https://issues.apache.org/jira/browse/CALCITE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767578#comment-17767578
]
Zoltan Haindrich commented on CALCITE-6020:
---
[~jhyde]: I've tried to look after the origins of this - but the history of
this leads back further than the "Eigenbase source files" commit.
Is there any reason to keep this behaviour?
> SqlToRelConverter should not replace windowed SUM with equivalent expression
> using SUM0
> ---
>
> Key: CALCITE-6020
> URL: https://issues.apache.org/jira/browse/CALCITE-6020
> Project: Calcite
> Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> {{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
> This might have been needed at some point in the past - but I think it will
> be better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the
> system that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it
> - as see
> [here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5984) Cannot fully disable trimming unused fields using Calcite configs
[
https://issues.apache.org/jira/browse/CALCITE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5984:
Labels: pull-request-available (was: )
> Cannot fully disable trimming unused fields using Calcite configs
> -
>
> Key: CALCITE-5984
> URL: https://issues.apache.org/jira/browse/CALCITE-5984
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.34.0
>Reporter: Wegdan Ghazi
>Priority: Major
> Labels: pull-request-available
>
> In Prepare#prepareSql there are 2 instances of trimming unused fields
> 1.
> [Prepare#trimUnusedFields|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L375]
> called
> [here|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L297]
>
> {code:java}
> // Trim unused fields.
> root = trimUnusedFields(root); {code}
> 2.
> {color:#172b4d}[TrimFieldsProgram|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/tools/Programs.java#L369]{color}
> called
> [here|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L312]
> within
> {code:java}
> root = optimize(root, getMaterializations(), getLattices());
> {code}
> I want to turn of the field trimming due to a personalisation I'm
> implementing to scan a specific API, which I would think is possible using
> [SqlConverter.Config|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L6085C20-L6085C26]
> I attempted to disable the trimming using hooks [PROGRAM,
> SQL2REL_CONVERTER_CONFIG_BUILDER], which succeeded to remove the trimming
> program, yet on
> [Prepare#trimUnusedFields|https://github.com/apache/calcite/blob/64268b9dd70bcdc15a3421ab120b8e5ecba17339/core/src/main/java/org/apache/calcite/prepare/Prepare.java#L375]
> {code:java}
> // code placehprotected RelRoot trimUnusedFields(RelRoot root) {
> final SqlToRelConverter.Config config = SqlToRelConverter.config()
> .withTrimUnusedFields(shouldTrim(root.rel))
> .withExpand(THREAD_EXPAND.get())
>
> .withInSubQueryThreshold(castNonNull(THREAD_INSUBQUERY_THRESHOLD.get()));
> final SqlToRelConverter converter =
> getSqlToRelConverter(getSqlValidator(), catalogReader, config);
> final boolean ordered = !root.collation.getFieldCollations().isEmpty();
> final boolean dml = SqlKind.DML.contains(root.kind);
> return root.withRel(converter.trimUnusedFields(dml || ordered, root.rel));
> }
> {code}
> The config passed (and edited by the hook) gets overwritten and only
> _shouldTrim(root.rel)_ can enable/disable trimming, I would expect this to
> happen iff the config _withTrimUnusedFields_ is only set to {_}true{_}.
> Is this the intended behaviour? Any help is appreciated, thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6020) SqlToRelConverter should not replace windowed SUM with equivalent expression using SUM0
Zoltan Haindrich created CALCITE-6020:
-
Summary: SqlToRelConverter should not replace windowed SUM with
equivalent expression using SUM0
Key: CALCITE-6020
URL: https://issues.apache.org/jira/browse/CALCITE-6020
Project: Calcite
Issue Type: Improvement
Reporter: Zoltan Haindrich
Assignee: Zoltan Haindrich
{{SqlToRelConverter}} replaces {{SUM}} with {{SUM0}} around
[here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5885]
This might have been needed at some point in the past - but I think it will be
better to leave it as {{SUM}} - as in case there is no {{SUM0}} in the system
that will be replaced with a {{COALESCE(SUM(...) , 0 )}} to provide it - as see
[here|https://github.com/apache/calcite/blob/e1991e08a225ef08c2402ab35c310d88fff3c222/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1288]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6009) Add optimization to remove redundant Limit when its input's row number is less or equal to Limit's fetch
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6009:
--
Issue Type: New Feature (was: Improvement)
> Add optimization to remove redundant Limit when its input's row number is
> less or equal to Limit's fetch
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6011:
--
Issue Type: New Feature (was: Improvement)
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6011) Add the RelRule that pushes the Filter past a Window
[
https://issues.apache.org/jira/browse/CALCITE-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen reassigned CALCITE-6011:
-
Assignee: LakeShen
> Add the RelRule that pushes the Filter past a Window
>
>
> Key: CALCITE-6011
> URL: https://issues.apache.org/jira/browse/CALCITE-6011
> Project: Calcite
> Issue Type: Improvement
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> The Filter condition could be pushed past the Window when condition used
> columns is window partition columns.
> For example:
> {code:java}
> SELECT
> *
> FROM
> (
> SELECT
> custkey,
> orderkey,
> rank() OVER (
> PARTITION BY custkey
> ORDER BY
> orderdate ASC
> )
> FROM
> orders
> )
> WHERE
> custkey = 0
> AND orderkey > 0 {code}
> The plan tree:
> {code:java}
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[AND(=($0, 0), >($1, 0))])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because the window partition columns is custkey,so the condition `custkey = 0
> ` could be pushed down the LogicalWindow.
> After that,the plan is :
> {code:java}
>
> LogicalProject(custkey=[0], orderkey=[$1], EXPR$2=[$2])
> LogicalFilter(condition=[>($1, 0)])
> LogicalProject(custkey=[$1], orderkey=[$0], EXPR$2=[$3])
> LogicalWindow(window#0=[window(partition {1} order by [2] aggs
> [RANK()])])
> LogicalFilter(condition=[=($1, 0)])
> LogicalProject(ORDERKEY=[$0], CUSTKEY=[$1], ORDERDATE=[$4])
> LogicalTableScan(table=[[tpch, ORDERS]])
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6009) Add optimization to remove redundant Limit when its input's row number is less or equal to Limit's fetch
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6009:
--
Summary: Add optimization to remove redundant Limit when its input's row
number is less or equal to Limit's fetch (was: Add optimization to remove Sort
when its input's row number is less or equal to one)
> Add optimization to remove redundant Limit when its input's row number is
> less or equal to Limit's fetch
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Priority: Major
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6009) Add optimization to remove redundant Limit when its input's row number is less or equal to Limit's fetch
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen reassigned CALCITE-6009:
-
Assignee: LakeShen
> Add optimization to remove redundant Limit when its input's row number is
> less or equal to Limit's fetch
>
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6009) Add optimization to remove Sort when its input's row number is less or equal to one
[
https://issues.apache.org/jira/browse/CALCITE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-6009:
--
Summary: Add optimization to remove Sort when its input's row number is
less or equal to one (was: Add the optimize for removing the redundant Limit
when a Limit's source row number less than Limit's fetch)
> Add optimization to remove Sort when its input's row number is less or equal
> to one
> ---
>
> Key: CALCITE-6009
> URL: https://issues.apache.org/jira/browse/CALCITE-6009
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Priority: Major
>
> In calcite,Limit would be represented by Sort,such as `LogicalSort[fetch =
> 5]`.
> When the Limit' source row number is less than the Limit's fetch,we could
> remove the the redundant Limit.
> For example:
> {code:java}
> SELECT * FROM (VALUES 1,2,3,4,5,6) AS t1 LIMIT 10 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[10])
> LogicalProject(t1=[$0])
> LogicalValues(tuples=[[{ 1 }, { 2 }, { 3 }, { 4 }, { 5 }, { 6 }]]) {code}
> Because the Limit's source max row number is 6,the Limit's fetch is 10,so we
> could remove the redundant Limit.
> Another example is :
> {code:java}
> SELECT count(*) FROM orders LIMIT 2 {code}
> The plan tree is :
> {code:java}
> LogicalSort(fetch=[2])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[tpch, ORDERS]]) {code}
> Because Limit's source max row number is 1,the Limit's fetch is 2, so we
> could remove the redundant Limit.
> The logic is same as presto's RemoveRedundantLimit
> rule:https://github.com/prestodb/presto/blob/50fbc07111ecca60a1a5e62755f095fa204120d0/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantLimit.java#L27
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5974) Elasticsearch adapter throws ClassCastException when index mapping sets dynamic_templates without properties
[
https://issues.apache.org/jira/browse/CALCITE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5974.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[e1991e08|https://github.com/apache/calcite/commit/e1991e08a225ef08c2402ab35c310d88fff3c222];
thanks for the PR, [~zoovwang]!
> Elasticsearch adapter throws ClassCastException when index mapping sets
> dynamic_templates without properties
>
>
> Key: CALCITE-5974
> URL: https://issues.apache.org/jira/browse/CALCITE-5974
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: zhaowang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When we use the elasticsearch-adapter, as we config an elasticsearch cluster,
> it will fetchMapping during initialization.
> If a index set dynamic_templates bug no mappings like this:
>
> {code:java}
> {
> "test_index" : {
> "mappings" : {
> "dynamic_templates" : [
> {
> "integers" : {
> "match_mapping_type" : "long",
> "mapping" : {
> "type" : "integer"
> }
> }
> }
> ]
> }
> }
> } {code}
> {{org.apache.calcite.adapter.elasticsearch.ElasticsearchJson#visitMappingProperties}}
> throw exception:
>
> {code:java}
> java.lang.ClassCastException:
> com.fasterxml.jackson.databind.node.ArrayNode cannot be cast to
> com.fasterxml.jackson.databind.node.ObjectNode
> at
>
> org.apache.calcite.adapter.elasticsearch.ElasticsearchJson.visitMappingProperties(ElasticsearchJson.java:133)
> {code}
> So ElasticsearchTransport initialize failed, all index of this es cluster
> access failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767445#comment-17767445
]
Ran Tao edited comment on CALCITE-5960 at 9/21/23 8:43 AM:
---
yes. I will rebase it. thanks. btw, can we safely close CALCITE-6012 ?
was (Author: lemonjing):
yes. I will rebase it. thanks. btw, i have removed the link of calcite-5948,
for this issue not block that now.
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[ https://issues.apache.org/jira/browse/CALCITE-5960 ]
Ran Tao deleted comment on CALCITE-5960:
--
was (Author: lemonjing):
[~julianhyde] can we safely close CALCITE-6012 ?
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
[jira] [Commented] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767464#comment-17767464
]
Ran Tao commented on CALCITE-5960:
--
[~julianhyde] can we safely close CALCITE-6012 ?
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Comment Edited] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767445#comment-17767445
]
Ran Tao edited comment on CALCITE-5960 at 9/21/23 8:38 AM:
---
yes. I will rebase it. thanks. btw, i have removed the link of calcite-5948,
for this issue not block that now.
was (Author: lemonjing):
yes. I will rebase it. thanks. btw, i have removed the link of calcite-5948,
for this issue not block that.
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Comment Edited] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767445#comment-17767445
]
Ran Tao edited comment on CALCITE-5960 at 9/21/23 8:37 AM:
---
yes. I will rebase it. thanks. btw, i have removed the link of calcite-5948,
for this issue not block that.
was (Author: lemonjing):
yes. I will rebase it. thanks.
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Comment Edited] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767453#comment-17767453
]
Ran Tao edited comment on CALCITE-5948 at 9/21/23 8:31 AM:
---
CALCITE-5960 has been resolved. the PR has rebased the main. So it only has one
single commit to solve this issue.
was (Author: lemonjing):
CALCITE-5960 has been solved. the PR has rebased the main. So it only has one
single commit to solve this issue.
> 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] [Comment Edited] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767453#comment-17767453
]
Ran Tao edited comment on CALCITE-5948 at 9/21/23 8:31 AM:
---
CALCITE-5960 has been resolved. this PR has rebased the main. So it only has
one single commit to solve this issue.
was (Author: lemonjing):
CALCITE-5960 has been resolved. the PR has rebased the main. So it only has one
single commit to solve this issue.
> 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] [Commented] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767453#comment-17767453
]
Ran Tao commented on CALCITE-5948:
--
CALCITE-5960 has been solved. the PR has rebased the main. So it only has one
single commit to solve this issue.
> 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] [Commented] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767445#comment-17767445
]
Ran Tao commented on CALCITE-5960:
--
yes. I will rebase it. thanks.
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Commented] (CALCITE-6017) The content of github link about the released versions in history doc is empty
[
https://issues.apache.org/jira/browse/CALCITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767443#comment-17767443
]
Julian Hyde commented on CALCITE-6017:
--
What happened on GitHub so that the list of releases is now empty? That is what
needs to be fixed.
> The content of github link about the released versions in history doc is empty
> --
>
> Key: CALCITE-6017
> URL: https://issues.apache.org/jira/browse/CALCITE-6017
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ran Tao
>Priority: Minor
> Labels: doc
> Attachments: image-2023-09-21-16-03-16-132.png,
> image-2023-09-21-16-04-00-579.png, image-2023-09-21-16-04-54-398.png
>
>
> In calcite history page, we have a description:
> {noformat}
> For a full list of releases, see
> https://github.com/apache/calcite/releases;>github.
> {noformat}
> however, there is nothing on this page, because calcite not use github to
> manage the released versions. So this description may seem a bit strange to
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6017) The content of github link about the released versions in history doc is empty
[
https://issues.apache.org/jira/browse/CALCITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767441#comment-17767441
]
Ran Tao commented on CALCITE-6017:
--
yes, the old archived link is correct. however, if we call
[https://github.com/apache/calcite/releases] directly, the page is nothing
unless we switch to tags.
!image-2023-09-21-16-04-54-398.png|width=485,height=186!
!image-2023-09-21-16-04-00-579.png|width=479,height=280!
> The content of github link about the released versions in history doc is empty
> --
>
> Key: CALCITE-6017
> URL: https://issues.apache.org/jira/browse/CALCITE-6017
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ran Tao
>Priority: Minor
> Labels: doc
> Attachments: image-2023-09-21-16-03-16-132.png,
> image-2023-09-21-16-04-00-579.png, image-2023-09-21-16-04-54-398.png
>
>
> In calcite history page, we have a description:
> {noformat}
> For a full list of releases, see
> https://github.com/apache/calcite/releases;>github.
> {noformat}
> however, there is nothing on this page, because calcite not use github to
> manage the released versions. So this description may seem a bit strange to
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6017) The content of github link about the released versions in history doc is empty
[
https://issues.apache.org/jira/browse/CALCITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6017:
-
Attachment: image-2023-09-21-16-04-00-579.png
> The content of github link about the released versions in history doc is empty
> --
>
> Key: CALCITE-6017
> URL: https://issues.apache.org/jira/browse/CALCITE-6017
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ran Tao
>Priority: Minor
> Labels: doc
> Attachments: image-2023-09-21-16-03-16-132.png,
> image-2023-09-21-16-04-00-579.png, image-2023-09-21-16-04-54-398.png
>
>
> In calcite history page, we have a description:
> {noformat}
> For a full list of releases, see
> https://github.com/apache/calcite/releases;>github.
> {noformat}
> however, there is nothing on this page, because calcite not use github to
> manage the released versions. So this description may seem a bit strange to
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6017) The content of github link about the released versions in history doc is empty
[
https://issues.apache.org/jira/browse/CALCITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6017:
-
Attachment: image-2023-09-21-16-04-54-398.png
> The content of github link about the released versions in history doc is empty
> --
>
> Key: CALCITE-6017
> URL: https://issues.apache.org/jira/browse/CALCITE-6017
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ran Tao
>Priority: Minor
> Labels: doc
> Attachments: image-2023-09-21-16-03-16-132.png,
> image-2023-09-21-16-04-00-579.png, image-2023-09-21-16-04-54-398.png
>
>
> In calcite history page, we have a description:
> {noformat}
> For a full list of releases, see
> https://github.com/apache/calcite/releases;>github.
> {noformat}
> however, there is nothing on this page, because calcite not use github to
> manage the released versions. So this description may seem a bit strange to
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6017) The content of github link about the released versions in history doc is empty
[
https://issues.apache.org/jira/browse/CALCITE-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6017:
-
Attachment: image-2023-09-21-16-03-16-132.png
> The content of github link about the released versions in history doc is empty
> --
>
> Key: CALCITE-6017
> URL: https://issues.apache.org/jira/browse/CALCITE-6017
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ran Tao
>Priority: Minor
> Labels: doc
> Attachments: image-2023-09-21-16-03-16-132.png
>
>
> In calcite history page, we have a description:
> {noformat}
> For a full list of releases, see
> https://github.com/apache/calcite/releases;>github.
> {noformat}
> however, there is nothing on this page, because calcite not use github to
> manage the released versions. So this description may seem a bit strange to
> end users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5960.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[3775307e|https://github.com/apache/calcite/commit/3775307e0b490f1bdad1555809d6bace073c2547];
thanks for the PR, [~taoran]!
I have not merged the other commit in the PR; can you please rebase the PR on
the latest main?
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Fix For: 1.36.0
>
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Resolved] (CALCITE-5995) Add cache to the dejsonize functions (JSON_VALUE, JSON_EXISTS, JSON_QUERY)
[
https://issues.apache.org/jira/browse/CALCITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5995.
--
Resolution: Fixed
Fixed in
[1cc1eb3a|https://github.com/apache/calcite/commit/1cc1eb3a477ce7687436024b4760cf1f04a80cbc];
thanks for the PR, [~zhoujira86]!
> Add cache to the dejsonize functions (JSON_VALUE, JSON_EXISTS, JSON_QUERY)
> --
>
> Key: CALCITE-5995
> URL: https://issues.apache.org/jira/browse/CALCITE-5995
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: xiaogang zhou
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I used the json_value function to parse json values. And I found calcite's
> json_value function does not cache the dejsonized objects, which could cause
> some performance issue in situation below as the dejsonize function being
> called repeatedly unnecessarily.
>
> {code:java}
> select
> json_value(A, 'xxx'),
> json_value(A, 'yyy'),
> json_value(A, 'zzz'),...
> from some_table;
> {code}
>
>
> As project like flink uses the json_value to codegen it's own json_value
> function, I think this could cause a bad performance for users. So I suggest
> to introduce a cache in
>
> org.apache.calcite.runtime.JsonFunctions#dejsonize
>
> and the solution is very common in projects like hive
> [https://github.com/apache/hive/blob/storage-branch-2.3/ql/src/java/org/apache/hadoop/hive/ql/udf/generic/GenericUDTFJSONTuple.java]
>
> and of course, this feature can be turned on only some certain config is
> setted. And if this is acceptable, I think I can take the ticket. thx
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5995) Add cache to the dejsonize functions (JSON_VALUE, JSON_EXISTS, JSON_QUERY)
[
https://issues.apache.org/jira/browse/CALCITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5995:
-
Summary: Add cache to the dejsonize functions (JSON_VALUE, JSON_EXISTS,
JSON_QUERY) (was: add cache to dejsonize function in JsonFunctions)
> Add cache to the dejsonize functions (JSON_VALUE, JSON_EXISTS, JSON_QUERY)
> --
>
> Key: CALCITE-5995
> URL: https://issues.apache.org/jira/browse/CALCITE-5995
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: xiaogang zhou
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I used the json_value function to parse json values. And I found calcite's
> json_value function does not cache the dejsonized objects, which could cause
> some performance issue in situation below as the dejsonize function being
> called repeatedly unnecessarily.
>
> {code:java}
> select
> json_value(A, 'xxx'),
> json_value(A, 'yyy'),
> json_value(A, 'zzz'),...
> from some_table;
> {code}
>
>
> As project like flink uses the json_value to codegen it's own json_value
> function, I think this could cause a bad performance for users. So I suggest
> to introduce a cache in
>
> org.apache.calcite.runtime.JsonFunctions#dejsonize
>
> and the solution is very common in projects like hive
> [https://github.com/apache/hive/blob/storage-branch-2.3/ql/src/java/org/apache/hadoop/hive/ql/udf/generic/GenericUDTFJSONTuple.java]
>
> and of course, this feature can be turned on only some certain config is
> setted. And if this is acceptable, I think I can take the ticket. thx
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5995) add cache to dejsonize function in JsonFunctions
[
https://issues.apache.org/jira/browse/CALCITE-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5995:
Labels: pull-request-available (was: )
> add cache to dejsonize function in JsonFunctions
>
>
> Key: CALCITE-5995
> URL: https://issues.apache.org/jira/browse/CALCITE-5995
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: xiaogang zhou
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> I used the json_value function to parse json values. And I found calcite's
> json_value function does not cache the dejsonized objects, which could cause
> some performance issue in situation below as the dejsonize function being
> called repeatedly unnecessarily.
>
> {code:java}
> select
> json_value(A, 'xxx'),
> json_value(A, 'yyy'),
> json_value(A, 'zzz'),...
> from some_table;
> {code}
>
>
> As project like flink uses the json_value to codegen it's own json_value
> function, I think this could cause a bad performance for users. So I suggest
> to introduce a cache in
>
> org.apache.calcite.runtime.JsonFunctions#dejsonize
>
> and the solution is very common in projects like hive
> [https://github.com/apache/hive/blob/storage-branch-2.3/ql/src/java/org/apache/hadoop/hive/ql/udf/generic/GenericUDTFJSONTuple.java]
>
> and of course, this feature can be turned on only some certain config is
> setted. And if this is acceptable, I think I can take the ticket. thx
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5989) Type inference for RPAD and LPAD functions (BIGQUERY) is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L updated CALCITE-5989: --- Fix Version/s: 1.36.0 > Type inference for RPAD and LPAD functions (BIGQUERY) is incorrect > -- > > Key: CALCITE-5989 > URL: https://issues.apache.org/jira/browse/CALCITE-5989 > 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 > > > The type inference uses the type `ReturnTypes.ARG0_NULLABLE_VARYING` for the > output. > This means that the output cannot be longer than arg0. This bug surfaces when > the query is optimized. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767428#comment-17767428
]
Ran Tao commented on CALCITE-5960:
--
[~vladimirsitnikov] got it. thanks for reviewing this.
> CAST failed if SqlTypeFamily of targetType is NULL
> --
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
> interval to number. but it throws NPE when family is null.
> It will cause some types such as row type (family is null) raise a NPE.
> e.g. If we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {noformat}
> java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
> row(a integer, b tinyint)))": Unable to implement
> EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
> $t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B)
> NOT NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0
> cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 13
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
> 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.testCastRow(SqlOperatorTest.java:6103)
> 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
>
[jira] [Resolved] (CALCITE-5994) Add optimization rule to remove Sort when its input's row number is less or equal to one
[
https://issues.apache.org/jira/browse/CALCITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-5994.
Resolution: Fixed
Done via
[{{1775baf}}|https://github.com/apache/calcite/commit/1775baf2184bc2d10b4991a2dea7e60c474bb5fc]
Thanks [~shenlang] for the patch!
> Add optimization rule to remove Sort when its input's row number is less or
> equal to one
>
>
> Key: CALCITE-5994
> URL: https://issues.apache.org/jira/browse/CALCITE-5994
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort's input source max row numer is 1,then we could remove the
> redundant Sort,the Sort could be a sorted semantic Sort(offset and fetch is
> null).
> For example,the sql:
> {code:java}
> select * from (select * from tableA limit 1) order by c ;
> {code}
> because the `(select * from tableA limit 1) ` max row number is 1, then we
> could remove order by c
> {code:java}
> select * from tableA limit 1;
> {code}
> The sql:
> {code:java}
> select max(totalprice) from orders order by 1 {code}
> could converted to:
> {code:java}
> select max(totalprice) from orders{code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantSort|https://github.com/prestodb/presto/blob/c21fc28846252cd910d90f046514bf586d7bb5c6/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantSort.java#L27]
> rule:
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6008) ARRAY_AGG should returns ARRAY NULL when there's no input rows
[ https://issues.apache.org/jira/browse/CALCITE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767410#comment-17767410 ] Julian Hyde commented on CALCITE-6008: -- Please ask for reviewers on the dev list. > ARRAY_AGG should returns ARRAY NULL when there's no input rows > -- > > Key: CALCITE-6008 > URL: https://issues.apache.org/jira/browse/CALCITE-6008 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.35.0 >Reporter: Jiabao Sun >Assignee: Jiabao Sun >Priority: Major > Labels: pull-request-available > > ARRAY_AGG in BigQuery and Postgres returns NULL if there are zero input rows > or expression evaluates to NULL for all rows. > However, it will return `ARRAY NOT NULL` in the return type of the > function definition. > [https://cloud.google.com/bigquery/docs/reference/standard-sql/aggregate_functions#array_agg] > [https://www.postgresql.org/docs/8.4/functions-aggregate.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6019) Excessive cast when UDF receives nullable JavaType
[
https://issues.apache.org/jira/browse/CALCITE-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6019:
---
Affects Version/s: 1.35.0
1.27.0
> Excessive cast when UDF receives nullable JavaType
> --
>
> Key: CALCITE-6019
> URL: https://issues.apache.org/jira/browse/CALCITE-6019
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0, 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> See CALCITE-6018, however, CALCITE-6018 is about the "ability to declare
> nullable, non-optional parameter" while this issue is about the excessive NOT
> NULL cast.
> Just in case, adding {{@Strict}} to {{retainedSize}} does not make CAST go
> away.
> It causes weird "cast(... NOT NULL)" even though my {{retainedSize}} function
> processes null just fine.
> {noformat}
> expr#4=[TO_HEAP_REFERENCE($t3)],
> expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
> expr#6=[retainedSize($t5)],
> {noformat}
> {{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
> [https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28]
> {{retainedSize}} receives a single (nullable) {{Object}} parameter, and it is
> declared as
> [https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129]
> I tried adding {{@Parameter(optional=true)}} to {{{}retainedSize{}}}, and it
> does not eliminate {{NOT NULL}} part of the cast.
>
> My expectation is that NOT NULL must not be there as both return type and the
> parameter type are nullable. It might be cast should not be there as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6019) Excessive cast when UDF receives nullable JavaType
Vladimir Sitnikov created CALCITE-6019:
--
Summary: Excessive cast when UDF receives nullable JavaType
Key: CALCITE-6019
URL: https://issues.apache.org/jira/browse/CALCITE-6019
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Vladimir Sitnikov
See CALCITE-6018, however, CALCITE-6018 is about the "ability to declare
nullable, non-optional parameter" while this issue is about the excessive NOT
NULL cast.
Just in case, adding {{@Strict}} to {{retainedSize}} does not make CAST go away.
It causes weird "cast(... NOT NULL)" even though my {{retainedSize}} function
processes null just fine.
{noformat}
expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)],
{noformat}
{{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
[https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28]
{{retainedSize}} receives a single (nullable) {{Object}} parameter, and it is
declared as
[https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129]
I tried adding {{@Parameter(optional=true)}} to {{{}retainedSize{}}}, and it
does not eliminate {{NOT NULL}} part of the cast.
My expectation is that NOT NULL must not be there as both return type and the
parameter type are nullable. It might be cast should not be there as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6018) Support nullable parameters in UDFs
[
https://issues.apache.org/jira/browse/CALCITE-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-6018:
---
Description:
Currently Calcite treats almost all the parameters as non-nullable. There's
{{@Parameter(optional=true)}}, however, it mixes "optionality" vs "nullability".
In other words, I would like to have nullable, non-optional parameters in UDFs.
For instance, Calcite could pick up nullness information from annotations (e.g.
`@Nullable`). For instance, Kotlin compiler generates the annotations
automatically, so I think supporting more-or-less standard tools like jspecify
and checkerframework should be preferred over Calcite-only annotations.
---
Sample usage: {{retainedSize}} is declared as
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129,
and I want to declare that {{retainedSize}} is fine to receive {{null}}
parameter.
was:
Currently Calcite treats almost all the parameters as non-nullable. There's
{{@Parameter(optional=true)}}, however, it mixes "optionality" vs "nullability".
It causes weird "cast(... NOT NULL)" even though my function processes null
just fine.
See example in CALCITE-6012.
{noformat}
expr#4=[TO_HEAP_REFERENCE($t3)],
expr#5=[CAST($t4):JavaType(class java.lang.Object) NOT NULL],
expr#6=[retainedSize($t5)],
{noformat}
{{TO_HEAP_REFERENCE}} returns nullable {{HeapReference}} (Java class):
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/schema/objects/HeapOperatorTable.java#L27-L28
{{retainedSize}} is declared as
https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129
I tried adding {{@Parameter(optional=true)}} to {{retainedSize}}, and it does
not remove the cast. It does not eliminate {{NOT NULL}} part of the cast.
---
In any case, I think it is not quite right to mix nullaness and optionally
concepts, and Calcite should inter nullness from nullability annotations.
> Support nullable parameters in UDFs
> ---
>
> Key: CALCITE-6018
> URL: https://issues.apache.org/jira/browse/CALCITE-6018
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently Calcite treats almost all the parameters as non-nullable. There's
> {{@Parameter(optional=true)}}, however, it mixes "optionality" vs
> "nullability".
> In other words, I would like to have nullable, non-optional parameters in
> UDFs.
> For instance, Calcite could pick up nullness information from annotations
> (e.g. `@Nullable`). For instance, Kotlin compiler generates the annotations
> automatically, so I think supporting more-or-less standard tools like
> jspecify and checkerframework should be preferred over Calcite-only
> annotations.
> ---
> Sample usage: {{retainedSize}} is declared as
> https://github.com/vlsi/mat-calcite-plugin/blob/4d4aa2284eeec69bc51da0c2e769ded06ef9ab97/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/functions/HeapFunctions.java#L129,
> and I want to declare that {{retainedSize}} is fine to receive {{null}}
> parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
