[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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
> org.junit.platform.engine.support.hierarchical.Throw
[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&focusedCommentId=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
> org.junit.jupiter.engine.descripto
[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&focusedCommentId=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
> org.junit.platfo
[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&focusedCommentId=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:
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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
> org.junit.jupiter.engine.descriptor.TestMethodTestDe
[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&focusedCommentId=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&focusedCommentId=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
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(Thro
[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&focusedCommentId=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
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor
[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)
