[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=17768947#comment-17768947
]
Oliver Lee commented on CALCITE-5955:
-
One more thing to note... it appears ISO SQL and BigQuery allows for different
clauses following PERCENTILE_CONT:
BigQuery would allow something like
{quote}SELECT PERCENTILE_CONT(product_id, 0.5) OVER (PARTITION BY
product_class_id ORDER BY net_weight)
{quote}
whereas ISO SQL would expect
{quote}SELECT PERCENTILE_CONT( 0.5) WITHIN GROUP (ORDER BY net_weight) OVER
(PARTITION BY product_class_id)
{quote}
Note that in BQ, they are mixed in with 1 {{OVER}} clause, and ISO SQL has
WITHIN GROUP as well as OVER.
Currently the SQL statement in BQ does get parsed into
{{LogicalProject}}
{{-> exps = [RexOver]}}
-> {{rexOver.rexWindow has partitionKeys}} and {{orderKeys}}
This makes me think that we actually do want a {{RexOver}} node to represent
BigQuery. [~julianhyde] could you help provide some input?
If we want to keep it parsed as a RexOver node, then the changes I would make
would be to Parser.jj to do lookaheads and maybe individually detect for
percentile_cont with a big-query-style over clause
> 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=17768946#comment-17768946
]
Oliver Lee commented on CALCITE-5955:
-
Putting breakpoints in the test Tanner has set up, I see that the {{RelNode}}
for the current BigQuery {{PERCENTILE_CONT2 at this
[point|https://github.com/apache/calcite/blob/cc73aba9b4af0c3af5ac96422518a821e951cb9b/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L7646]
is a LogicalProject}} with a {{RexOver that has {{op}} of
{{{}SqlBasicAggFunction.PERCENTILE_CONT{}}}2}}
When I send in SQL for non-BQ syntax/library, the {{RelNode}} is a
{{LogicalAggregate}} with {{aggFunction}}
{{SqlBasicAggFunction.PERCENTILE_CONT}}
I think the desired behavior [~julianhyde] is describing is that we want the
new PERCENTILE_CONT2 to be parsed such that it is a {{LogicalAggregate}} and
not a {{RexOver}}
To me this sounds like we would need parser level changes to handle this since
the
[current|https://github.com/apache/calcite/blob/cc73aba9b4af0c3af5ac96422518a821e951cb9b/core/src/main/codegen/templates/Parser.jj#L4068]
PercentileFunctionCall() parsing notes that WITHIN GROUP and OVER is handled
outside of that
> 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=17768926#comment-17768926
]
Oliver Lee commented on CALCITE-5955:
-
I'm trying to catch up on the current development and PR for this Jira ticket.
After reading the BQ docs on window functions, I do have to say that what
BigQuery syntax shows is deceivingly similar to what a "window function" is.
The docs point `percentile_cont` to window functions and meets what the window
function documentation defines as the requirement for being a window function.
It says
{quote}{{PERCENTILE_CONT (value_expression, percentile [{RESPECT | IGNORE}
NULLS])
OVER over_clause}}
{{}}
To learn more about the {{OVER}} clause and how to use it, see [Window function
calls|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls].
{{...-> A window function includes an {{OVER}} clause }}
{quote}
Going off of this Oracle diagram [here
|https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/PERCENTILE_CONT.html#GUID-CA259452-A565-41B3-A4F4-DD74B66CEDE0]I
can also see Julians point about it not being a window function, it just
happens to swap out the words {{WITHIN GROUP}} with {{OVER}}
> 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-6025) Simplify DECODE function
[ https://issues.apache.org/jira/browse/CALCITE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768875#comment-17768875 ] Julian Hyde commented on CALCITE-6025: -- I don't think we should simplify DECODE. Why? I think of DECODE as syntactic sugar for CASE. As such, simplify should work on the CASE expression that has been created from DECODE. If generating SQL for a dialect that supports DECODE, we could convert CASE back to DECODE. > Simplify DECODE function > > > Key: CALCITE-6025 > URL: https://issues.apache.org/jira/browse/CALCITE-6025 > Project: Calcite > Issue Type: Improvement >Reporter: Wenzhuang Zhu >Assignee: Wenzhuang Zhu >Priority: Minor > > RexSimplify.simplify supports COALESCE and CASE, but DECODE is not supported. > > DECODE function: decode(, , [, , > ]...[, ]) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-6024:
Assignee: Julian Hyde
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768872#comment-17768872
]
Julian Hyde commented on CALCITE-6024:
--
I'm working on it already.
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768825#comment-17768825
]
Julian Hyde commented on CALCITE-6023:
--
Regarding formatting. I recommend using \{code} and \{noformat} tokens at the
beginning and end of multi-line blocks. I've made those changes to the
description.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {noformat}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {noformat}
> SQL:
> {code}
> SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"
> FROM (
> SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"
> GROUP BY "dim4"
> {code}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
>
> Below is the way I am invoking convertQuery. The error comes in the last
> line, on invocation of convertQuery
> {code}
> var config = Frameworks.newConfigBuilder()
> .operatorTable(getOperatorTable())
> .parserConfig(defaultParserConfig().build())
> .build();
> var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
> var typeFactory = new JavaTypeFactoryImpl();
> var calciteSchema = buildCalciteSchema(typeFactory, schema);
> var catalogReader = new CalciteCatalogReader(
> calciteSchema,
> List.of(),
> typeFactory,
> CalciteConnectionConfig.DEFAULT);
> var validator = new SqlValidatorImpl(
> getOperatorTable(),
> catalogReader,
> typeFactory,
> SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
> var vol = new VolcanoPlanner();
> vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
> var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
> var sqlToRel = new SqlToRelConverter(
> NOOP_EXPANDER,
> validator,
> catalogReader,
> cluster,
> StandardConvertletTable.INSTANCE,
> SqlToRelConverter.config());
> return sqlToRel.convertQuery(sqlNode, true, true);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6023:
-
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{noformat}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{noformat}
SQL:
{code}
SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"
FROM (
SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"
GROUP BY "dim4"
{code}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{code}
var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true);
{code}
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{var config = Frameworks.newConfigBuilder()}}
{{ .operatorTable(getOperatorTable())}}
{{ .parserConfig(defaultParserConfig().build())}}
{{ .build();}}
{{var sqlNode = Frameworks.getPlanner(config).parse(sqlString);}}
{{var typeFactory = new JavaTypeFactoryImpl();}}
{{var calciteSchema = buildCalciteSchema(typeFactory, schema);}}
{{var catalogReader = new CalciteCatalogReader(}}
{{ calciteSchema,}}
{{ List.of(),}}
{{ typeFactory,}}
{{ CalciteConnectionConfig.DEFAULT);}}
{{var validator = new SqlValidatorImpl(}}
{{ getOperatorTable(),}}
{{ catalogReader,}}
{{ typeFactory,}}
{{ SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};}}
{{var vol = new VolcanoPlanner();}}
{{vol.addRelTraitDef(ConventionTraitDef.INSTANCE);}}
{{var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));}}
{{var sqlToRel = new SqlToRelConverter(}}
{{ NOOP_EXPANDER,}}
{{ validator,}}
{{ catalogReader,}}
{{ cluster,}}
{{ StandardConvertletTable.INSTANCE,}}
{{ SqlToRelConverter.config());}}
{{return sqlToRel.convertQuery(sqlNode, true, true);}}
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have
[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=17768815#comment-17768815
]
Julian Hyde commented on CALCITE-6017:
--
I agree with [~rubenql]. The tags will have a few extra entries - the release
candidates, including the failed ones - but that information may also be useful
to the reader.
[~taoran], Thank you for taking the time to research and document the cause of
this problem.
> 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
>Assignee: 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-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=17768776#comment-17768776
]
Wenrui Meng commented on CALCITE-6007:
--
[~julianhyde] could you help review the change?
> 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
>Assignee: Wenrui Meng
>Priority: Major
> Labels: pull-request-available
>
> {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-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=17768725#comment-17768725
]
Ruben Q L commented on CALCITE-6017:
Thanks for digging into this, [~taoran]. Looking at your analysis, IMHO
replacing the link with "tags" seems a reasonable way to fix this issue.
> 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
>Assignee: 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] [Comment Edited] (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=17768676#comment-17768676
]
Ran Tao edited comment on CALCITE-6017 at 9/25/23 1:49 PM:
---
I think I got the reason from
[https://github.com/orgs/community/discussions/6396]. The early behavior of
GitHub was that if there was no release, the tag would be displayed, but after
2021.10, these two functions were decoupled, so the release is empty unless the
release is explicitly specified (however calcite not use GitHub to publish
release artifacts).
we can see from end of 2021, there is empty.
[https://web.archive.org/web/20211219215203/https://github.com/apache/calcite/releases]
Considering that very early calcite release pages in GitHub are tags actually.
e.g. [releases as of 2021-03-06 per Wayback
machine|https://web.archive.org/web/20210306054735/https://github.com/apache/calcite/releases].
IMHO, we can use tags explicitly to replace this link either.
[~julianhyde] [~shenlang] any suggestions? what do you think?
was (Author: lemonjing):
I think I got the reason from
[https://github.com/orgs/community/discussions/6396]. The early behavior of
GitHub was that if there was no release, the tag would be displayed, but after
2021.10, these two functions were decoupled, so the release is empty unless the
release is explicitly specified (however calcite not use GitHub to publish
release artifacts).
we can see from end of 2021, there is empty.
[https://web.archive.org/web/20211219215203/https://github.com/apache/calcite/releases]
Considering that very early calcite release pages in GitHub are tags actually.
e.g. [releases as of 2021-03-06 per Wayback
machine|https://web.archive.org/web/20210306054735/https://github.com/apache/calcite/releases].
IMHO, we can use tags explicitly to replace this link either.
[~julianhyde] hi, Julian, what do you think?
> 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
>Assignee: 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-5940) Add the Rule to optimize Limit
[
https://issues.apache.org/jira/browse/CALCITE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5940:
--
Summary: Add the Rule to optimize Limit (was: Add the Rules to optimize
Limit)
> Add the Rule to optimize Limit
> --
>
> Key: CALCITE-5940
> URL: https://issues.apache.org/jira/browse/CALCITE-5940
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Now in calcite,the Limit will be represented using
> LogicalSort(fetch=[xx]),but there are few rules to optimize Limit.
> In trino and presto,there are many optimization rules to optimize Limit.
> For example,the sql:
> {code:java}
> select * from nation limit 0 {code}
> The limit 0 will use empty ValuesNode(Calcite LogicalValues) to optimize,so
> the SQL is not delivered to the Worker compute,the rule could see:
> [EvaluateZeroLimit|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/EvaluateZeroLimit.java#L28C1-L28C31]
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (select * from nation limit 1) limit
> 10 {code}
> It would be optimized by
> [MergeLimits|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimits.java#L26]
> rule to:
> {code:java}
> select concat('-',N_REGIONKEY) from nation limit 10 {code}
> The value of limit takes the minimum of the outer limit and the inner limit.
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (SELECT * FROM nation order BY
> N_REGIONKEY DESC LIMIT 1) limit 10 {code}
> It would be optimized by
> [MergeLimitWithTopN|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimitWithTopN.java#L28C1-L28C31]
> rule to:
> {code:java}
> SELECT concat('-',N_REGIONKEY) FROM nation order BY N_REGIONKEY DESC LIMIT
> 10{code}
> So I propose to add these three rules to Calcite as well, to optimize the
> Limit case.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768690#comment-17768690
]
Jordan Hannel edited comment on CALCITE-6023 at 9/25/23 1:22 PM:
-
Thanks both for the quick responses! I have updated the issue subject and body
as requested.
Re. "calling the parser and sql-to-rel-converter by hand", could you elaborate
on this? I've updated the issue description above to include the code I'm using
to call the parser and converter, is there a different recommended way?
Thanks for the attempted repro, I wonder if the issue has something to do with
a subquery in the from clause - maybe the below query might repro the
issue?}}{}}}
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "deptno" AS "dim4" FROM emp) AS "t0"}}
{{GROUP BY "dim4"}}
was (Author: JIRAUSER302326):
Thanks both for the quick responses! I have updated the issue subject and body
as requested.
Re. "calling the parser and sql-to-rel-converter by hand", could you elaborate
on this? I've updated the issue description above to include the code I'm using
to call the parser and converter, is there a different recommended way?
Thanks for the attempted repro, I wonder if the issue has something to do with
a subquery in the from clause - maybe the below query might repro the
issue?{{{}{}}}
SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "deptno" AS "dim4" FROM emp) AS "t0"}}
{{GROUP BY "dim4"
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
>
> Below is the way I am invoking convertQuery. The error comes in the last
> line, on invocation of convertQuery
> {{var config = Frameworks.newConfigBuilder()}}
> {{ .operatorTable(getOperatorTable())}}
> {{ .parserConfig(defaultParserConfig().build())}}
> {{ .build();}}
> {{var sqlNode = Frameworks.getPlanner(config).parse(sqlString);}}
> {{var typeFactory = new JavaTypeFactoryImpl();}}
> {{var calciteSchema = buildCalciteSchema(typeFactory, schema);}}
> {{var catalogReader = new CalciteCatalogReader(}}
> {{ calciteSchema,}}
> {{ List.of(),}}
> {{ typeFactory,}}
> {{ CalciteConnectionConfig.DEFAULT);}}
> {{var validator = new SqlValidatorImpl(}}
> {{ getOperatorTable(),}}
> {{ catalogReader,}}
> {{ typeFactory,}}
> {{ SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};}}
> {{var vol = new VolcanoPlanner();}}
> {{vol.addRelTraitDef(ConventionTraitDef.INSTANCE);}}
> {{var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));}}
> {{var sqlToRel = new SqlToRelConverter(}}
> {{ NOOP_EXPANDER,}}
> {{ validator,}}
> {{ catalogReader,}}
> {{ cluster,}}
> {{ StandardConvertletTable.INSTANCE,}}
> {{ SqlToRelConverter.config());}}
> {{return sqlToRel.convertQuery(sqlNode, true, true);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768690#comment-17768690
]
Jordan Hannel edited comment on CALCITE-6023 at 9/25/23 1:22 PM:
-
Thanks both for the quick responses! I have updated the issue subject and body
as requested.
Re. "calling the parser and sql-to-rel-converter by hand", could you elaborate
on this? I've updated the issue description above to include the code I'm using
to call the parser and converter, is there a different recommended way?
Thanks for the attempted repro, I wonder if the issue has something to do with
a subquery in the from clause - maybe the below query might repro the
issue?{{{}{}}}
SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "deptno" AS "dim4" FROM emp) AS "t0"}}
{{GROUP BY "dim4"
was (Author: JIRAUSER302326):
Thanks both for the quick responses! I have updated the issue subject and body
as requested.
Re. "calling the parser and sql-to-rel-converter by hand", could you elaborate
on this? I've updated the issue description above to include the code I'm using
to call the parser and converter, is there a different recommended way?
Thanks for the attempted repro, I wonder if the issue has something to do with
a subquery in the from clause - maybe the below query might repro the issue?
SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"
FROM (
SELECT "deptno" AS "dim4" FROM emp) AS "t0"
GROUP BY "dim4"
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
>
> Below is the way I am invoking convertQuery. The error comes in the last
> line, on invocation of convertQuery
> {{var config = Frameworks.newConfigBuilder()}}
> {{ .operatorTable(getOperatorTable())}}
> {{ .parserConfig(defaultParserConfig().build())}}
> {{ .build();}}
> {{var sqlNode = Frameworks.getPlanner(config).parse(sqlString);}}
> {{var typeFactory = new JavaTypeFactoryImpl();}}
> {{var calciteSchema = buildCalciteSchema(typeFactory, schema);}}
> {{var catalogReader = new CalciteCatalogReader(}}
> {{ calciteSchema,}}
> {{ List.of(),}}
> {{ typeFactory,}}
> {{ CalciteConnectionConfig.DEFAULT);}}
> {{var validator = new SqlValidatorImpl(}}
> {{ getOperatorTable(),}}
> {{ catalogReader,}}
> {{ typeFactory,}}
> {{ SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};}}
> {{var vol = new VolcanoPlanner();}}
> {{vol.addRelTraitDef(ConventionTraitDef.INSTANCE);}}
> {{var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));}}
> {{var sqlToRel = new SqlToRelConverter(}}
> {{ NOOP_EXPANDER,}}
> {{ validator,}}
> {{ catalogReader,}}
> {{ cluster,}}
> {{ StandardConvertletTable.INSTANCE,}}
> {{ SqlToRelConverter.config());}}
> {{return sqlToRel.convertQuery(sqlNode, true, true);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768690#comment-17768690
]
Jordan Hannel commented on CALCITE-6023:
Thanks both for the quick responses! I have updated the issue subject and body
as requested.
Re. "calling the parser and sql-to-rel-converter by hand", could you elaborate
on this? I've updated the issue description above to include the code I'm using
to call the parser and converter, is there a different recommended way?
Thanks for the attempted repro, I wonder if the issue has something to do with
a subquery in the from clause - maybe the below query might repro the issue?
SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"
FROM (
SELECT "deptno" AS "dim4" FROM emp) AS "t0"
GROUP BY "dim4"
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
>
> Below is the way I am invoking convertQuery. The error comes in the last
> line, on invocation of convertQuery
> {{var config = Frameworks.newConfigBuilder()}}
> {{ .operatorTable(getOperatorTable())}}
> {{ .parserConfig(defaultParserConfig().build())}}
> {{ .build();}}
> {{var sqlNode = Frameworks.getPlanner(config).parse(sqlString);}}
> {{var typeFactory = new JavaTypeFactoryImpl();}}
> {{var calciteSchema = buildCalciteSchema(typeFactory, schema);}}
> {{var catalogReader = new CalciteCatalogReader(}}
> {{ calciteSchema,}}
> {{ List.of(),}}
> {{ typeFactory,}}
> {{ CalciteConnectionConfig.DEFAULT);}}
> {{var validator = new SqlValidatorImpl(}}
> {{ getOperatorTable(),}}
> {{ catalogReader,}}
> {{ typeFactory,}}
> {{ SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};}}
> {{var vol = new VolcanoPlanner();}}
> {{vol.addRelTraitDef(ConventionTraitDef.INSTANCE);}}
> {{var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));}}
> {{var sqlToRel = new SqlToRelConverter(}}
> {{ NOOP_EXPANDER,}}
> {{ validator,}}
> {{ catalogReader,}}
> {{ cluster,}}
> {{ StandardConvertletTable.INSTANCE,}}
> {{ SqlToRelConverter.config());}}
> {{return sqlToRel.convertQuery(sqlNode, true, true);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{
var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true);
}}
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true);}}
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{var config = Frameworks.newConfigBuilder()}}
{{ .operatorTable(getOperatorTable())}}
{{ .parserConfig(defaultParserConfig().build())}}
{{ .build();}}
{{var sqlNode = Frameworks.getPlanner(config).parse(sqlString);}}
{{var typeFactory = new JavaTypeFactoryImpl();}}
{{var calciteSchema = buildCalciteSchema(typeFactory, schema);}}
{{var catalogReader = new CalciteCatalogReader(}}
{{ calciteSchema,}}
{{ List.of(),}}
{{ typeFactory,}}
{{ CalciteConnectionConfig.DEFAULT);}}
{{var validator = new SqlValidatorImpl(}}
{{ getOperatorTable(),}}
{{ catalogReader,}}
{{ typeFactory,}}
{{ SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};}}
{{var vol = new VolcanoPlanner();}}
{{vol.addRelTraitDef(ConventionTraitDef.INSTANCE);}}
{{var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));}}
{{var sqlToRel = new SqlToRelConverter(}}
{{ NOOP_EXPANDER,}}
{{ validator,}}
{{ catalogReader,}}
{{ cluster,}}
{{ StandardConvertletTable.INSTANCE,}}
{{ SqlToRelConverter.config());}}
{{return sqlToRel.convertQuery(sqlNode, true, true);}}
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{
var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true);
}}
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convertQuery
{{var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true);}}
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convert
{{
var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true)
}}
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached.
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
Below is the way I am invoking convertQuery. The error comes in the last line,
on invocation of convert
{{
var config = Frameworks.newConfigBuilder()
.operatorTable(getOperatorTable())
.parserConfig(defaultParserConfig().build())
.build();
var sqlNode = Frameworks.getPlanner(config).parse(sqlString);
var typeFactory = new JavaTypeFactoryImpl();
var calciteSchema = buildCalciteSchema(typeFactory, schema);
var catalogReader = new CalciteCatalogReader(
calciteSchema,
List.of(),
typeFactory,
CalciteConnectionConfig.DEFAULT);
var validator = new SqlValidatorImpl(
getOperatorTable(),
catalogReader,
typeFactory,
SqlValidator.Config.DEFAULT.withCallRewrite(false)) {};
var vol = new VolcanoPlanner();
vol.addRelTraitDef(ConventionTraitDef.INSTANCE);
var cluster = RelOptCluster.create(vol, new RexBuilder(typeFactory));
var sqlToRel = new SqlToRelConverter(
NOOP_EXPANDER,
validator,
catalogReader,
cluster,
StandardConvertletTable.INSTANCE,
SqlToRelConverter.config());
return sqlToRel.convertQuery(sqlNode, true, true)
}}
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
>
> Below is the way I am invoking convertQuery. The error comes in the last
> line, on invocation of convert
> {{
> var config = Frameworks.newConfigBuilder()
>
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT( * )) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT( * ), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
"t0" GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM (}}
{{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10"}}
{{FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
{{GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10"}}
> {{FROM (}}
> {{ SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS "t0"}}
> {{GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
"t0" GROUP BY "dim4"}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{
SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
"t0" GROUP BY "dim4"
}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"}}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[
https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Hannel updated CALCITE-6023:
---
Description:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
{quote}UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
{quote}
SQL:
{{
SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
"t0" GROUP BY "dim4"
}}
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
was:
Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
repro are outlined below, and the full stacktrace is attached. This is on
calcite version 1.35.0. Any insight would be much appreciated, thanks!
When I parse the below SQL string to get a SqlNode, and call
SqlToRelConverter.convertQuery on this SqlNode, I get error:
```
UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall:
LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
```
SQL:
```
SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
"measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
"t0" GROUP BY "dim4"
```
I have confirmed that my SqlToRelConverter instance seems generally ok, because
it is able to convert many other SqlNodes to RelNodes. After some
experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
"t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
translated to a RelNode.
> Error in SqlToRelConverter.convertQuery, possibly due to unqualified column
> reference
> -
>
> Key: CALCITE-6023
> URL: https://issues.apache.org/jira/browse/CALCITE-6023
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Jordan Hannel
>Priority: Major
> Attachments: stacktrace.txt
>
>
> Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and
> repro are outlined below, and the full stacktrace is attached. This is on
> calcite version 1.35.0. Any insight would be much appreciated, thanks!
> When I parse the below SQL string to get a SqlNode, and call
> SqlToRelConverter.convertQuery on this SqlNode, I get error:
> {quote}UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: LEAD(COUNT(*)) OVER (ORDER BY `dim4`)
> {quote}
> SQL:
> {{
> SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS
> "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS
> "t0" GROUP BY "dim4"
> }}
> I have confirmed that my SqlToRelConverter instance seems generally ok,
> because it is able to convert many other SqlNodes to RelNodes. After some
> experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY
> "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is
> translated to a RelNode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6023) Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference
[ https://issues.apache.org/jira/browse/CALCITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Hannel updated CALCITE-6023: --- Summary: Error in SqlToRelConverter.convertQuery, possibly due to unqualified column reference (was: Possible bug found in SqlToRelConverter) > Error in SqlToRelConverter.convertQuery, possibly due to unqualified column > reference > - > > Key: CALCITE-6023 > URL: https://issues.apache.org/jira/browse/CALCITE-6023 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.35.0 >Reporter: Jordan Hannel >Priority: Major > Attachments: stacktrace.txt > > > Hello all, I believe I have found a bug in SqlToRelConverter. The symptom and > repro are outlined below, and the full stacktrace is attached. This is on > calcite version 1.35.0. Any insight would be much appreciated, thanks! > When I parse the below SQL string to get a SqlNode, and call > SqlToRelConverter.convertQuery on this SqlNode, I get error: > ``` > UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall: > LEAD(COUNT(*)) OVER (ORDER BY `dim4`) > ``` > SQL: > ``` > SELECT "dim4" AS "dim7", LEAD(COUNT(*), -1) OVER (ORDER BY "dim4") AS > "measure10" FROM ( SELECT "timestamp" AS "dim4" FROM "Shared.factDataset") AS > "t0" GROUP BY "dim4" > ``` > I have confirmed that my SqlToRelConverter instance seems generally ok, > because it is able to convert many other SqlNodes to RelNodes. After some > experimentation, I noticed that just changing `ORDER BY "dim4"` to `ORDER BY > "t0"."dim4"` fixes the issue - after that, the SqlNode successfully is > translated to a RelNode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (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 reassigned CALCITE-6017:
Assignee: Ran Tao
> 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
>Assignee: 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] [Comment Edited] (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=17768676#comment-17768676
]
Ran Tao edited comment on CALCITE-6017 at 9/25/23 12:52 PM:
I think I got the reason from
[https://github.com/orgs/community/discussions/6396]. The early behavior of
GitHub was that if there was no release, the tag would be displayed, but after
2021.10, these two functions were decoupled, so the release is empty unless the
release is explicitly specified (however calcite not use GitHub to publish
release artifacts).
we can see from end of 2021, there is empty.
[https://web.archive.org/web/20211219215203/https://github.com/apache/calcite/releases]
Considering that very early calcite release pages in GitHub are tags actually.
e.g. [releases as of 2021-03-06 per Wayback
machine|https://web.archive.org/web/20210306054735/https://github.com/apache/calcite/releases].
IMHO, we can use tags explicitly to replace this link either.
[~julianhyde] hi, Julian, what do you think?
was (Author: lemonjing):
I think I got the reason from
https://github.com/orgs/community/discussions/6396. The early behavior of
GitHub was that if there was no release, the tag would be displayed, but after
2021.10, these two functions were decoupled, so the release is empty unless the
release is displayed (however calcite not use GitHub to publish release
artifacts).
we can see from end of 2021, there is empty.
[https://web.archive.org/web/20211219215203/https://github.com/apache/calcite/releases]
Considering that very early calcite release pages in GitHub are tags actually.
e.g. [releases as of 2021-03-06 per Wayback
machine|https://web.archive.org/web/20210306054735/https://github.com/apache/calcite/releases].
IMHO, we can use tags explicitly to replace this link either.
[~julianhyde] hi, Julian, what do you think?
> 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=17768676#comment-17768676
]
Ran Tao commented on CALCITE-6017:
--
I think I got the reason from
https://github.com/orgs/community/discussions/6396. The early behavior of
GitHub was that if there was no release, the tag would be displayed, but after
2021.10, these two functions were decoupled, so the release is empty unless the
release is displayed (however calcite not use GitHub to publish release
artifacts).
we can see from end of 2021, there is empty.
[https://web.archive.org/web/20211219215203/https://github.com/apache/calcite/releases]
Considering that very early calcite release pages in GitHub are tags actually.
e.g. [releases as of 2021-03-06 per Wayback
machine|https://web.archive.org/web/20210306054735/https://github.com/apache/calcite/releases].
IMHO, we can use tags explicitly to replace this link either.
[~julianhyde] hi, Julian, what do you think?
> 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-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768654#comment-17768654
]
Ran Tao commented on CALCITE-6024:
--
+1 for this issue, I'm glad to fix this if it hasn't been started yet.
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6025) Simplify DECODE function
[ https://issues.apache.org/jira/browse/CALCITE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wenzhuang Zhu updated CALCITE-6025: --- Description: RexSimplify.simplify supports COALESCE and CASE, but DECODE is not supported. DECODE function: decode(, , [, , ]...[, ]) > Simplify DECODE function > > > Key: CALCITE-6025 > URL: https://issues.apache.org/jira/browse/CALCITE-6025 > Project: Calcite > Issue Type: Improvement >Reporter: Wenzhuang Zhu >Assignee: Wenzhuang Zhu >Priority: Minor > > RexSimplify.simplify supports COALESCE and CASE, but DECODE is not supported. > > DECODE function: decode(, , [, , > ]...[, ]) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6025) Simplify DECODE function
[ https://issues.apache.org/jira/browse/CALCITE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768572#comment-17768572 ] Ran Tao commented on CALCITE-6025: -- Maybe we should add description to explain this ticket? > Simplify DECODE function > > > Key: CALCITE-6025 > URL: https://issues.apache.org/jira/browse/CALCITE-6025 > Project: Calcite > Issue Type: Improvement >Reporter: Wenzhuang Zhu >Assignee: Wenzhuang Zhu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6025) Simplify DECODE function
Wenzhuang Zhu created CALCITE-6025: -- Summary: Simplify DECODE function Key: CALCITE-6025 URL: https://issues.apache.org/jira/browse/CALCITE-6025 Project: Calcite Issue Type: Improvement Reporter: Wenzhuang Zhu Assignee: Wenzhuang Zhu -- This message was sent by Atlassian Jira (v8.20.10#820010)
