[jira] [Updated] (CALCITE-6118) Missing empty ARRAY function usage in reference doc
[ https://issues.apache.org/jira/browse/CALCITE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ran Tao updated CALCITE-6118: - Description: the default array constructor not allows empty array. however in https://issues.apache.org/jira/browse/CALCITE-5624 we have supported spark array function. spark array function allows empty, but the calcite doc not indicate this behavior, maybe we can add a usage for empty array function. was: the default array constructor not allow empty array. however in https://issues.apache.org/jira/browse/CALCITE-5624 we have supported spark array function. spark array function allows empty, but the calcite doc not indicate this behavior, maybe we can add a usage for empty array function. > Missing empty ARRAY function usage in reference doc > --- > > Key: CALCITE-6118 > URL: https://issues.apache.org/jira/browse/CALCITE-6118 > Project: Calcite > Issue Type: Improvement >Affects Versions: 1.36.0 >Reporter: Ran Tao >Priority: Minor > > the default array constructor not allows empty array. > however in https://issues.apache.org/jira/browse/CALCITE-5624 we have > supported spark array function. > spark array function allows empty, but the calcite doc not indicate this > behavior, maybe we can add a usage for empty array function. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6119) Upgrade test-containers to 1.19.1
Ran Tao created CALCITE-6119: Summary: Upgrade test-containers to 1.19.1 Key: CALCITE-6119 URL: https://issues.apache.org/jira/browse/CALCITE-6119 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.36.0 Reporter: Ran Tao One of the main features is a fixing for SELinux users. https://github.com/testcontainers/testcontainers-java/pull/6294 Also more release notes are at https://github.com/testcontainers/testcontainers-java/releases/tag/1.19.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6118) Missing empty ARRAY function usage in reference doc
[ https://issues.apache.org/jira/browse/CALCITE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ran Tao reassigned CALCITE-6118: Assignee: (was: Ran Tao) > Missing empty ARRAY function usage in reference doc > --- > > Key: CALCITE-6118 > URL: https://issues.apache.org/jira/browse/CALCITE-6118 > Project: Calcite > Issue Type: Improvement >Affects Versions: 1.36.0 >Reporter: Ran Tao >Priority: Minor > > the default array constructor not allow empty array. > however in https://issues.apache.org/jira/browse/CALCITE-5624 we have > supported spark array function. > spark array function allows empty, but the calcite doc not indicate this > behavior, maybe we can add a usage for empty array function. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6118) Missing empty ARRAY function usage in reference doc
Ran Tao created CALCITE-6118: Summary: Missing empty ARRAY function usage in reference doc Key: CALCITE-6118 URL: https://issues.apache.org/jira/browse/CALCITE-6118 Project: Calcite Issue Type: Improvement Affects Versions: 1.36.0 Reporter: Ran Tao Assignee: Ran Tao the default array constructor not allow empty array. however in https://issues.apache.org/jira/browse/CALCITE-5624 we have supported spark array function. spark array function allows empty, but the calcite doc not indicate this behavior, maybe we can add a usage for empty array function. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6112) Use indelible release tags
[
https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785751#comment-17785751
]
Vladimir Sitnikov commented on CALCITE-6112:
> inedible
I should have written uneditable :D
I just tried git push -f gh
2326cf8dc97f473d0efa2b0e4883fef87a40746b:calcite-1.28.0, and it worked.
{noformat}
To https://github.com/apache/calcite.git
+ 18b044d72...2326cf8dc 2326cf8dc97f473d0efa2b0e4883fef87a40746b ->
calcite-1.28.0 (forced update)
{noformat}
Then I reverted with git push -f gh
dec167ac18272c0cd8be477d6b162d7a31a62114:calcite-1.28.0
> Should we keep tagging as vX.Y.Z, supplement it with a rel/vX.Y.Z tag, or
> eschew the vX.Y.Z tag completely
You might probably ask infra to make rel/... customizable via .asf.yaml as well.
> Use indelible release tags
> --
>
> Key: CALCITE-6112
> URL: https://issues.apache.org/jira/browse/CALCITE-6112
> Project: Calcite
> Issue Type: Improvement
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> The ASF has recommended using indelible Git tags (rel/...) since 2016:
> [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs]
> It turns out that has broken in Calcite since 2020:
> [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6111) Explicit cast from expression to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6111:
Labels: pull-request-available (was: )
> Explicit cast from expression to numeric type doesn't check overflow
>
>
> Key: CALCITE-6111
> URL: https://issues.apache.org/jira/browse/CALCITE-6111
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> After [1] was implemented it is still possible to obtain erroneous result,
> check:
> {code:java}
> SELECT cast(100+30 as tinyint);{code}
> result:
> {code:java}
> -126{code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5990
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5846) Preserve filters on non-distinct aggCalls in AggregateExpandWithinDistinctRule
[ https://issues.apache.org/jira/browse/CALCITE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanner Clary resolved CALCITE-5846. --- Fix Version/s: 1.37.0 Resolution: Fixed Merged via [83d320c|https://github.com/apache/calcite/commit/83d320c2ebcb1eff9f61d26a1b86979e7b266496], thanks for the PR, [~tjbanghart]! > Preserve filters on non-distinct aggCalls in AggregateExpandWithinDistinctRule > -- > > Key: CALCITE-5846 > URL: https://issues.apache.org/jira/browse/CALCITE-5846 > Project: Calcite > Issue Type: Bug >Reporter: Steven Talbot >Assignee: TJ Banghart >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > This line > [https://github.com/apache/calcite/blob/2dba40e7a0a5651eac5a30d9e0a72f178bd9bff2/core/src/main/java/org/apache/calcite/rel/rules/AggregateExpandWithinDistinctRule.java#L346-L348] > drops any such filterArg. > Related to CALCITE-4726. When the rule was first introduced any such > aggregates were blocked, but that change lets them through. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6117) Converting SAFE_CAST from RexCall to SqlCall fails to add the type as an argument
[
https://issues.apache.org/jira/browse/CALCITE-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6117:
Summary: Converting SAFE_CAST from RexCall to SqlCall fails to add the type
as an argument (was: Unparsing SAFE_CAST is broken)
> Converting SAFE_CAST from RexCall to SqlCall fails to add the type as an
> argument
> -
>
> Key: CALCITE-6117
> URL: https://issues.apache.org/jira/browse/CALCITE-6117
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Trivial
> Labels: pull-request-available
>
> BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
> unparsing logic is broken because it does not use the [special logic for
> {{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
> in {{SqlImplementor.callToSql}} that turns the rex call's return type into
> the sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6102) SqlWriter in SqlInsert's unparse start a list but does not end it
[
https://issues.apache.org/jira/browse/CALCITE-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mingcan Wang updated CALCITE-6102:
--
Description:
SqlWriter in SqlInsert's unparse() start a list but does not end it.
There is a SparkSql :
{code:java}
with tmp as (select * from t1) insert into t2 select * from tmp {code}
I know calcite doesn't support parse "CTE + DML" for now.
But in some situation, I'll create a SqlNode like that.
{code:java}
SqlInsert sqlinsert;
SqlWith sqlWith;
//
sqlWith.setOperand(1, sqlInsert);
sqlWith.toString(); {code}
if we put a SqlInsert into a SqlWith's body manually, when we unparse the
SqlWith , it will throw an Expception :
{code:java}
java.lang.IllegalArgumentException: Frame does not match current frame
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
at
org.apache.calcite.sql.pretty.SqlPrettyWriter.endList(SqlPrettyWriter.java:884)
at org.apache.calcite.sql.SqlWith$SqlWithOperator.unparse(SqlWith.java:109)
{code}
was:
SqlWriter in SqlInsert's unparse() start a list but does not end it.
if we put a SqlInsert into a SqlWith's body, when we unparse the SqlWith , it
will throw an Expception :
java.lang.IllegalArgumentException: Frame does not match current frame
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
at
org.apache.calcite.sql.pretty.SqlPrettyWriter.endList(SqlPrettyWriter.java:884)
at org.apache.calcite.sql.SqlWith$SqlWithOperator.unparse(SqlWith.java:109)
> SqlWriter in SqlInsert's unparse start a list but does not end it
> -
>
> Key: CALCITE-6102
> URL: https://issues.apache.org/jira/browse/CALCITE-6102
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mingcan Wang
>Assignee: Mingcan Wang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> SqlWriter in SqlInsert's unparse() start a list but does not end it.
> There is a SparkSql :
> {code:java}
> with tmp as (select * from t1) insert into t2 select * from tmp {code}
> I know calcite doesn't support parse "CTE + DML" for now.
> But in some situation, I'll create a SqlNode like that.
> {code:java}
> SqlInsert sqlinsert;
> SqlWith sqlWith;
> //
> sqlWith.setOperand(1, sqlInsert);
> sqlWith.toString(); {code}
> if we put a SqlInsert into a SqlWith's body manually, when we unparse the
> SqlWith , it will throw an Expception :
> {code:java}
> java.lang.IllegalArgumentException: Frame does not match current frame
>
> at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
> at
> org.apache.calcite.sql.pretty.SqlPrettyWriter.endList(SqlPrettyWriter.java:884)
> at org.apache.calcite.sql.SqlWith$SqlWithOperator.unparse(SqlWith.java:109)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6102) SqlWriter in SqlInsert's unparse start a list but does not end it
[
https://issues.apache.org/jira/browse/CALCITE-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785726#comment-17785726
]
Mingcan Wang commented on CALCITE-6102:
---
[~jiajunbernoulli] ok, I just update the description , and add a SQL example
> SqlWriter in SqlInsert's unparse start a list but does not end it
> -
>
> Key: CALCITE-6102
> URL: https://issues.apache.org/jira/browse/CALCITE-6102
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mingcan Wang
>Assignee: Mingcan Wang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> SqlWriter in SqlInsert's unparse() start a list but does not end it.
> There is a SparkSql :
> {code:java}
> with tmp as (select * from t1) insert into t2 select * from tmp {code}
> I know calcite doesn't support parse "CTE + DML" for now.
> But in some situation, I'll create a SqlNode like that.
> {code:java}
> SqlInsert sqlinsert;
> SqlWith sqlWith;
> //
> sqlWith.setOperand(1, sqlInsert);
> sqlWith.toString(); {code}
> if we put a SqlInsert into a SqlWith's body manually, when we unparse the
> SqlWith , it will throw an Expception :
> {code:java}
> java.lang.IllegalArgumentException: Frame does not match current frame
>
> at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
> at
> org.apache.calcite.sql.pretty.SqlPrettyWriter.endList(SqlPrettyWriter.java:884)
> at org.apache.calcite.sql.SqlWith$SqlWithOperator.unparse(SqlWith.java:109)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6117) Unparsing SAFE_CAST is broken
[
https://issues.apache.org/jira/browse/CALCITE-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785722#comment-17785722
]
Tanner Clary commented on CALCITE-6117:
---
Thanks for the clarification I think the PR looks good :)
> Unparsing SAFE_CAST is broken
> -
>
> Key: CALCITE-6117
> URL: https://issues.apache.org/jira/browse/CALCITE-6117
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Trivial
> Labels: pull-request-available
>
> BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
> unparsing logic is broken because it does not use the [special logic for
> {{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
> in {{SqlImplementor.callToSql}} that turns the rex call's return type into
> the sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6117) Unparsing SAFE_CAST is broken
[
https://issues.apache.org/jira/browse/CALCITE-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785720#comment-17785720
]
Will Noble commented on CALCITE-6117:
-
It will trigger [this
assertion|https://github.com/apache/calcite/blob/3843ede3d28783235780c0f81f725dc7e64a7828/core/src/main/java/org/apache/calcite/sql/fun/SqlCastFunction.java#L254]
because the sql call only has 1 argument.
> Unparsing SAFE_CAST is broken
> -
>
> Key: CALCITE-6117
> URL: https://issues.apache.org/jira/browse/CALCITE-6117
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Trivial
> Labels: pull-request-available
>
> BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
> unparsing logic is broken because it does not use the [special logic for
> {{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
> in {{SqlImplementor.callToSql}} that turns the rex call's return type into
> the sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6117) Unparsing SAFE_CAST is broken
[
https://issues.apache.org/jira/browse/CALCITE-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6117:
Labels: pull-request-available (was: )
> Unparsing SAFE_CAST is broken
> -
>
> Key: CALCITE-6117
> URL: https://issues.apache.org/jira/browse/CALCITE-6117
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Trivial
> Labels: pull-request-available
>
> BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
> unparsing logic is broken because it does not use the [special logic for
> {{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
> in {{SqlImplementor.callToSql}} that turns the rex call's return type into
> the sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6083) On web site, ensure contributors file is sorted
[ https://issues.apache.org/jira/browse/CALCITE-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6083: Labels: pull-request-available (was: ) > On web site, ensure contributors file is sorted > --- > > Key: CALCITE-6083 > URL: https://issues.apache.org/jira/browse/CALCITE-6083 > Project: Calcite > Issue Type: Improvement >Reporter: Julian Hyde >Assignee: Mihai Budiu >Priority: Major > Labels: pull-request-available > > On web site, ensure contributors file is sorted. Add a test to LintTest to > keep it sorted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6102) SqlWriter in SqlInsert's unparse start a list but does not end it
[ https://issues.apache.org/jira/browse/CALCITE-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785716#comment-17785716 ] Jiajun Xie commented on CALCITE-6102: - [~jiefei30] You clearly explained the reason. If there were SQL examples to help users understand, it would be even better. > SqlWriter in SqlInsert's unparse start a list but does not end it > - > > Key: CALCITE-6102 > URL: https://issues.apache.org/jira/browse/CALCITE-6102 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mingcan Wang >Assignee: Mingcan Wang >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > SqlWriter in SqlInsert's unparse() start a list but does not end it. > if we put a SqlInsert into a SqlWith's body, when we unparse the SqlWith , it > will throw an Expception : > > java.lang.IllegalArgumentException: Frame does not match current frame > > at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122) > at > org.apache.calcite.sql.pretty.SqlPrettyWriter.endList(SqlPrettyWriter.java:884) > at org.apache.calcite.sql.SqlWith$SqlWithOperator.unparse(SqlWith.java:109) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6117) Unparsing SAFE_CAST is broken
[
https://issues.apache.org/jira/browse/CALCITE-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785705#comment-17785705
]
Tanner Clary commented on CALCITE-6117:
---
So how does it currently unparse? Is it always wrong?
> Unparsing SAFE_CAST is broken
> -
>
> Key: CALCITE-6117
> URL: https://issues.apache.org/jira/browse/CALCITE-6117
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Trivial
>
> BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
> unparsing logic is broken because it does not use the [special logic for
> {{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
> in {{SqlImplementor.callToSql}} that turns the rex call's return type into
> the sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6117) Unparsing SAFE_CAST is broken
Will Noble created CALCITE-6117:
---
Summary: Unparsing SAFE_CAST is broken
Key: CALCITE-6117
URL: https://issues.apache.org/jira/browse/CALCITE-6117
Project: Calcite
Issue Type: Bug
Reporter: Will Noble
BigQuery's {{SAFE_CAST}} function operates much like {{CAST}}. Currently, the
unparsing logic is broken because it does not use the [special logic for
{{CAST}}|https://github.com/apache/calcite/blob/94dc1673da824174f9271677ead73cfae1aeb29b/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L816]
in {{SqlImplementor.callToSql}} that turns the rex call's return type into the
sql call's second argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6111) Explicit cast from expression to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785697#comment-17785697
]
Mihai Budiu commented on CALCITE-6111:
--
The bug seems to be in RexToLixTranslator.checkExpressionPadTruncate, which is
called from RexToLixTranslator.translateCast.
This function does nothing for numeric casts, whereas it should generate code
to produce an exception if the cast overflows the target type.
> Explicit cast from expression to numeric type doesn't check overflow
>
>
> Key: CALCITE-6111
> URL: https://issues.apache.org/jira/browse/CALCITE-6111
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Mihai Budiu
>Priority: Major
>
> After [1] was implemented it is still possible to obtain erroneous result,
> check:
> {code:java}
> SELECT cast(100+30 as tinyint);{code}
> result:
> {code:java}
> -126{code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5990
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6111) Explicit cast from expression to numeric type doesn't check overflow
[
https://issues.apache.org/jira/browse/CALCITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu reassigned CALCITE-6111:
Assignee: Mihai Budiu
> Explicit cast from expression to numeric type doesn't check overflow
>
>
> Key: CALCITE-6111
> URL: https://issues.apache.org/jira/browse/CALCITE-6111
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Mihai Budiu
>Priority: Major
>
> After [1] was implemented it is still possible to obtain erroneous result,
> check:
> {code:java}
> SELECT cast(100+30 as tinyint);{code}
> result:
> {code:java}
> -126{code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5990
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6112) Use indelible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785440#comment-17785440 ] Francis Chuang edited comment on CALCITE-6112 at 11/13/23 8:50 PM: --- Avatica-go is a Go project and its release tags must be in the form vX.Y.Z in order to be discoverable by the modules/dependency system that is used by Go. What's the advice for this? Should we keep tagging as vX.Y.Z, supplement it with a rel/vX.Y.Z tag, or eschew the vX.Y.Z tag completely, leaving the rel/vX.Y.Z tag only (which will break go modules)? was (Author: francischuang): Avatica-go is a Go project and it's release tags must be in the form vX.Y.Z in order to be discoverable by the modules/dependency system that is used by Go. What's the advice for this? Should we keep tagging as vX.Y.Z, supplement it with a rel/vX.Y.Z tag, or eschew the vX.Y.Z tag completely, leaving the rel/vX.Y.Z tag only (which will break go modules)? > Use indelible release tags > -- > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using indelible Git tags (rel/...) since 2016: > [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs] > It turns out that has broken in Calcite since 2020: > [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6112) Use indelible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785661#comment-17785661 ] Julian Hyde commented on CALCITE-6112: -- I edited the summary and description, changing 'inedible' to 'indelible'. Our tags have always been [inedible|https://en.wiktionary.org/wiki/inedible]. :) > Use indelible release tags > -- > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using indelible Git tags (rel/...) since 2016: > [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs] > It turns out that has broken in Calcite since 2020: > [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6112) Use indelible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-6112: - Description: The ASF has recommended using indelible Git tags (rel/...) since 2016: [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs] It turns out that has broken in Calcite since 2020: [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000] was: The ASF has recommended using inedible Git tags (rel/...) since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 > Use indelible release tags > -- > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using indelible Git tags (rel/...) since 2016: > [https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs] > It turns out that has broken in Calcite since 2020: > [https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6112) Use indelible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-6112: - Summary: Use indelible release tags (was: Use inedible release tags) > Use indelible release tags > -- > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using inedible Git tags (rel/...) since 2016: > https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs > It turns out that has broken in Calcite since 2020: > https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6115) Interval type specifier with zero fractional second precision does not pass validation
[
https://issues.apache.org/jira/browse/CALCITE-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785543#comment-17785543
]
Leonid Chistov commented on CALCITE-6115:
-
See also SqlIntervalQualifier::evaluateIntervalLiteralAsDayToSecond.
It creates invalid pattern if `fractionalSecondPrecision` equals zero.
> Interval type specifier with zero fractional second precision does not pass
> validation
> --
>
> Key: CALCITE-6115
> URL: https://issues.apache.org/jira/browse/CALCITE-6115
> Project: Calcite
> Issue Type: Bug
>Reporter: Leonid Chistov
>Assignee: Leonid Chistov
>Priority: Major
>
> Consider interval expression
> {code:java}
> interval '1' second(1, 0) {code}
> Calcite SQL validator considers it as not correct, since it uses following
> lower bound for fractional seconds precision:
> {code:java}
> public static final int MIN_INTERVAL_FRACTIONAL_SECOND_PRECISION = 1;{code}
> In order to reproduce this issue one can add following test cast to
> SqlValidatorTest.java:
> {code:java}
> @Test void testSecondIntervalExpression() {
> expr("interval '1' second(1, 0)").columnType("INTERVAL SECOND(1, 0) NOT
> NULL");
> } {code}
> and get an error:
> {code:java}
> Interval fractional second precision '0' out of range for INTERVAL SECOND(1,
> 0) {code}
> However, SQL standard say:
> {code:java}
> An , if specified, shall be greater
> than or equal to 0 (zero)
> and shall not be greater than the implementation-defined maximum. If SECOND
> is specified
> and is not specified, then an
> precision> of 6 is implicit. {code}
> Consequently, MIN_INTERVAL_FRACTIONAL_SECOND_PRECISION should be equal to 0
> to make Calcite behavior consistent with SQL specification.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5888) Assertion error in aggregate
[
https://issues.apache.org/jira/browse/CALCITE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Masopust updated CALCITE-5888:
---
Affects Version/s: 1.36.0
> Assertion error in aggregate
>
>
> Key: CALCITE-5888
> URL: https://issues.apache.org/jira/browse/CALCITE-5888
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Petr Masopust
>Priority: Major
>
> We have {{relBuilder.aggregate(groupKey, aggregateCalls)}} in our code with
> values {{[AS($31, 'a_label_d_opp_stage_id_foodmart_bd4c9c91212f9f'),
> AS(CAST(FLOOR($34, FLAG(QUARTER))):TIMESTAMP(0),
> 'a_label_snapshot_timestamp_quarter_foodmart_89fe710c8628d9')]}} and
> {{[COUNT(CASE(AND(COALESCE($37, false), =($36, $13)), $15, null:NULL)),
> SUM(CASE(AND(COALESCE($37, false), =($36, $13)), $2, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL))].}}
> It works perfectly in version 1.34.0 but in 1.35.0 we got this exception:
> {{java.lang.AssertionError}}
> {{ at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)}}
> {{ at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:328)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2564)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2511)}}
> {{ at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2348)}}
>
> I think it is either missing {{permute}} or assert should compare
> {{cardinality}} instead of {{length.}} Because it compares field index? to
> number of fields which looks like nonsense to me.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6116) Add EXISTS function (enabled in Spark library)
hongyu guo created CALCITE-6116:
---
Summary: Add EXISTS function (enabled in Spark library)
Key: CALCITE-6116
URL: https://issues.apache.org/jira/browse/CALCITE-6116
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.36.0
Reporter: hongyu guo
Assignee: hongyu guo
Fix For: 1.37.0
exists(expr, pred) - Tests whether a predicate holds for one or more elements
in the array.
{code:sql}
> SELECT `EXISTS`(array(1, 2, 3), x -> x % 2 == 0);
true
> SELECT `EXISTS`(array(1, 2, 3), x -> x % 2 == 10);
false
> SELECT `EXISTS`(array(1, null, 3), x -> x % 2 == 0);
NULL
> SELECT `EXISTS`(array(0, null, 2, 3, null), x -> x IS NULL);
true
> SELECT `EXISTS`(array(1, 2, 3), x -> x IS NULL);
false
{code}
In Calcite, EXISTS is a keyword, so we need to specify the function with back
quotes.
Moreover, `EXISTS` is a higher-order function, and if we want to support
higher-order functions in Calcite, we must first support lambda expressions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6115) Interval type specifier with zero fractional second precision does not pass validation
Leonid Chistov created CALCITE-6115:
---
Summary: Interval type specifier with zero fractional second
precision does not pass validation
Key: CALCITE-6115
URL: https://issues.apache.org/jira/browse/CALCITE-6115
Project: Calcite
Issue Type: Bug
Reporter: Leonid Chistov
Assignee: Leonid Chistov
Consider interval expression
{code:java}
interval '1' second(1, 0) {code}
Calcite SQL validator considers it as not correct, since it uses following
lower bound for fractional seconds precision:
{code:java}
public static final int MIN_INTERVAL_FRACTIONAL_SECOND_PRECISION = 1;{code}
In order to reproduce this issue one can add following test cast to
SqlValidatorTest.java:
{code:java}
@Test void testSecondIntervalExpression() {
expr("interval '1' second(1, 0)").columnType("INTERVAL SECOND(1, 0) NOT
NULL");
} {code}
and get an error:
{code:java}
Interval fractional second precision '0' out of range for INTERVAL SECOND(1, 0)
{code}
However, SQL standard say:
{code:java}
An , if specified, shall be greater than
or equal to 0 (zero)
and shall not be greater than the implementation-defined maximum. If SECOND is
specified
and is not specified, then an of 6 is implicit. {code}
Consequently, MIN_INTERVAL_FRACTIONAL_SECOND_PRECISION should be equal to 0 to
make Calcite behavior consistent with SQL specification.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved CALCITE-6113. -- Fix Version/s: avatica-1.24.0 Resolution: Fixed Committed to main. Thanks for the review [~francischuang] . > Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in > Avatica > -- > > Key: CALCITE-6113 > URL: https://issues.apache.org/jira/browse/CALCITE-6113 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Fix For: avatica-1.24.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We are currently using 5.1.x for both, which is quite old. > Upgrade to the latest GA versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6113: - Issue Type: Task (was: Bug) > Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in > Avatica > -- > > Key: CALCITE-6113 > URL: https://issues.apache.org/jira/browse/CALCITE-6113 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently using 5.1.x for both, which is quite old. > Upgrade to the latest GA versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6114) RexExecutor fails on interval expressions with fractional second parts
Leonid Chistov created CALCITE-6114:
---
Summary: RexExecutor fails on interval expressions with fractional
second parts
Key: CALCITE-6114
URL: https://issues.apache.org/jira/browse/CALCITE-6114
Project: Calcite
Issue Type: Bug
Affects Versions: 1.35.0
Reporter: Leonid Chistov
Consider query like:
{code:java}
select interval 1.234 second as inr
from "scott".emp {code}
When trying to run expression reduce step on that query, RexExecutor fails with
following error:
{code:java}
Exception in thread "main" java.lang.RuntimeException: while resolving method
'multiply[class java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:449)
at
org.apache.calcite.adapter.enumerable.RexImpTable$BinaryImplementor.implementSafe(RexImpTable.java:2797)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3691)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3643)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1184)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:209)
{code}
The reason why expression reduction step is required for such expressions is
that interval expressions are internally translated to multiplication
expressions like:
{code:java}
*(1.234:decimal32(4, 3), 1000:interval_second(2, 6)) {code}
In order to reproduce the issue, one can add following test case to the
"misc.iq" file and run CoreQuidemTest:
{code:java}
!ok
# Interval expressions
select interval 1.234 second as inr
from "scott".emp;
+---+--++-+
| INR |
+---+--++-+
| 1.234 |
+---+--++-+
(1 rows) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6112) Use inedible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785440#comment-17785440 ] Francis Chuang commented on CALCITE-6112: - Avatica-go is a Go project and it's release tags must be in the form vX.Y.Z in order to be discoverable by the modules/dependency system that is used by Go. What's the advice for this? Should we keep tagging as vX.Y.Z, supplement it with a rel/vX.Y.Z tag, or eschew the vX.Y.Z tag completely, leaving the rel/vX.Y.Z tag only (which will break go modules)? > Use inedible release tags > - > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using inedible Git tags (rel/...) since 2016: > https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs > It turns out that has broken in Calcite since 2020: > https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6113: - Description: We are currently using 5.1.x for both, which is quite old. Upgrade to the latest GA versions. was:We are currently using 5.1.x for both, which is quite old. > Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in > Avatica > -- > > Key: CALCITE-6113 > URL: https://issues.apache.org/jira/browse/CALCITE-6113 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently using 5.1.x for both, which is quite old. > Upgrade to the latest GA versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6113: Labels: pull-request-available (was: ) > Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in > Avatica > -- > > Key: CALCITE-6113 > URL: https://issues.apache.org/jira/browse/CALCITE-6113 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently using 5.1.x for both, which is quite old. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6113: - Description: We are currently using 5.1.x for both, which is quite old. > Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in > Avatica > -- > > Key: CALCITE-6113 > URL: https://issues.apache.org/jira/browse/CALCITE-6113 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > We are currently using 5.1.x for both, which is quite old. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6113) Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica
Istvan Toth created CALCITE-6113: Summary: Update HttpComponents Core to 5.2.3 and HttpComponents Client to 5.2.1 in Avatica Key: CALCITE-6113 URL: https://issues.apache.org/jira/browse/CALCITE-6113 Project: Calcite Issue Type: Bug Components: avatica Reporter: Istvan Toth Assignee: Istvan Toth -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6112) Use inedible release tags
[ https://issues.apache.org/jira/browse/CALCITE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-6112: --- Description: The ASF has recommended using inedible Git tags (rel/...) since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 was: The ASF has recommended using inedible Git tags since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 > Use inedible release tags > - > > Key: CALCITE-6112 > URL: https://issues.apache.org/jira/browse/CALCITE-6112 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > > The ASF has recommended using inedible Git tags (rel/...) since 2016: > https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs > It turns out that has broken in Calcite since 2020: > https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6112) Use inedible release tags
Vladimir Sitnikov created CALCITE-6112: -- Summary: Use inedible release tags Key: CALCITE-6112 URL: https://issues.apache.org/jira/browse/CALCITE-6112 Project: Calcite Issue Type: Improvement Reporter: Vladimir Sitnikov The ASF has recommended using inedible Git tags since 2016: https://lists.apache.org/thread/szbtzk0048ppx1zvzljbrq7by2mt1zvs It turns out that has broken in Calcite since 2020: https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6108) SQL request to Avatica-Go returns 0s for float types
[
https://issues.apache.org/jira/browse/CALCITE-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Egor Ryashin updated CALCITE-6108:
--
Attachment: image-2023-11-13-12-03-43-954.png
> SQL request to Avatica-Go returns 0s for float types
>
>
> Key: CALCITE-6108
> URL: https://issues.apache.org/jira/browse/CALCITE-6108
> Project: Calcite
> Issue Type: Bug
> Components: avatica, avatica-go, druid-adapter
>Affects Versions: 1.35.0
>Reporter: Egor Ryashin
>Assignee: Francis Chuang
>Priority: Major
> Attachments: image-2023-11-11-20-42-55-846.png,
> image-2023-11-11-20-43-33-198.png, image-2023-11-11-20-43-49-485.png,
> image-2023-11-12-10-56-10-382.png, image-2023-11-13-12-03-43-954.png
>
>
> I have zeros for float types in Go client result set with Calcite 1.35 update
> in Apache Druid. It worked with an older version. From what I see in the
> debugger TypedValue.NumberValue = 0 but DoubleValue = 1. Not sure where's the
> bug exactly - Druid/Avatica.
> This is how it can be reproduced:
> {code:java}
> package main
> import (
> "database/sql"
> "fmt"
> _ "github.com/apache/calcite-avatica-go/v5"
> )
> func main() {
> jdbcUrl := "https://localhost/druid/v2/sql/avatica-protobuf";
> db, err := sql.Open("avatica", jdbcUrl)
> if err != nil {
> panic(err)
> }
> defer db.Close()
> sql4 := `
> SELECT
> cast(1.0 as double) m3
> `
> rows, err := db.Query(sql4)
> if err != nil {
> panic(err)
> }
> defer rows.Close()
> var m1 float32
> for rows.Next() {
> err := rows.Scan(&m1)
> if err != nil {
> panic(err)
> }
> fmt.Println(m1)
> }
> } {code}
> What I see in the debugger right now:
> !image-2023-11-11-20-43-49-485.png!
> This is what I see in the Druid debugger:
> !image-2023-11-11-20-42-55-846.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6108) SQL request to Avatica-Go returns 0s for float types
[
https://issues.apache.org/jira/browse/CALCITE-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785423#comment-17785423
]
Egor Ryashin commented on CALCITE-6108:
---
!image-2023-11-13-12-03-43-954.png!
> SQL request to Avatica-Go returns 0s for float types
>
>
> Key: CALCITE-6108
> URL: https://issues.apache.org/jira/browse/CALCITE-6108
> Project: Calcite
> Issue Type: Bug
> Components: avatica, avatica-go, druid-adapter
>Affects Versions: 1.35.0
>Reporter: Egor Ryashin
>Assignee: Francis Chuang
>Priority: Major
> Attachments: image-2023-11-11-20-42-55-846.png,
> image-2023-11-11-20-43-33-198.png, image-2023-11-11-20-43-49-485.png,
> image-2023-11-12-10-56-10-382.png, image-2023-11-13-12-03-43-954.png
>
>
> I have zeros for float types in Go client result set with Calcite 1.35 update
> in Apache Druid. It worked with an older version. From what I see in the
> debugger TypedValue.NumberValue = 0 but DoubleValue = 1. Not sure where's the
> bug exactly - Druid/Avatica.
> This is how it can be reproduced:
> {code:java}
> package main
> import (
> "database/sql"
> "fmt"
> _ "github.com/apache/calcite-avatica-go/v5"
> )
> func main() {
> jdbcUrl := "https://localhost/druid/v2/sql/avatica-protobuf";
> db, err := sql.Open("avatica", jdbcUrl)
> if err != nil {
> panic(err)
> }
> defer db.Close()
> sql4 := `
> SELECT
> cast(1.0 as double) m3
> `
> rows, err := db.Query(sql4)
> if err != nil {
> panic(err)
> }
> defer rows.Close()
> var m1 float32
> for rows.Next() {
> err := rows.Scan(&m1)
> if err != nil {
> panic(err)
> }
> fmt.Println(m1)
> }
> } {code}
> What I see in the debugger right now:
> !image-2023-11-11-20-43-49-485.png!
> This is what I see in the Druid debugger:
> !image-2023-11-11-20-42-55-846.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6108) SQL request to Avatica-Go returns 0s for float types
[
https://issues.apache.org/jira/browse/CALCITE-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785422#comment-17785422
]
Egor Ryashin commented on CALCITE-6108:
---
I believe, the bug is on Apache Druid side, see my debug effort in this channel
https://apachedruidworkspace.slack.com/archives/C0309C9L90D/p1699608729494169
> SQL request to Avatica-Go returns 0s for float types
>
>
> Key: CALCITE-6108
> URL: https://issues.apache.org/jira/browse/CALCITE-6108
> Project: Calcite
> Issue Type: Bug
> Components: avatica, avatica-go, druid-adapter
>Affects Versions: 1.35.0
>Reporter: Egor Ryashin
>Assignee: Francis Chuang
>Priority: Major
> Attachments: image-2023-11-11-20-42-55-846.png,
> image-2023-11-11-20-43-33-198.png, image-2023-11-11-20-43-49-485.png,
> image-2023-11-12-10-56-10-382.png
>
>
> I have zeros for float types in Go client result set with Calcite 1.35 update
> in Apache Druid. It worked with an older version. From what I see in the
> debugger TypedValue.NumberValue = 0 but DoubleValue = 1. Not sure where's the
> bug exactly - Druid/Avatica.
> This is how it can be reproduced:
> {code:java}
> package main
> import (
> "database/sql"
> "fmt"
> _ "github.com/apache/calcite-avatica-go/v5"
> )
> func main() {
> jdbcUrl := "https://localhost/druid/v2/sql/avatica-protobuf";
> db, err := sql.Open("avatica", jdbcUrl)
> if err != nil {
> panic(err)
> }
> defer db.Close()
> sql4 := `
> SELECT
> cast(1.0 as double) m3
> `
> rows, err := db.Query(sql4)
> if err != nil {
> panic(err)
> }
> defer rows.Close()
> var m1 float32
> for rows.Next() {
> err := rows.Scan(&m1)
> if err != nil {
> panic(err)
> }
> fmt.Println(m1)
> }
> } {code}
> What I see in the debugger right now:
> !image-2023-11-11-20-43-49-485.png!
> This is what I see in the Druid debugger:
> !image-2023-11-11-20-42-55-846.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
