[jira] [Commented] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459660#comment-17459660
]
Aleksey Plekhanov commented on CALCITE-4906:
[~nobigo], thanks for the review!
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4871) CAST a literal to DECIMAL type return wrong result
[
https://issues.apache.org/jira/browse/CALCITE-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong updated CALCITE-4871:
Fix Version/s: (was: 1.29.0)
> CAST a literal to DECIMAL type return wrong result
> --
>
> Key: CALCITE-4871
> URL: https://issues.apache.org/jira/browse/CALCITE-4871
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.28.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In calcite. The precision and scale can't work.
> 1) Add judgment in decimal type precision and scale parameter(When have
> illegal value need to throw an exception):
> SQL EXAMPLES:
> {code:java}
> cast(155.36 as decimal(0,0)){code}
> In Postgresql:
> {noformat}
> ERROR: NUMERIC precision 0 must be between 1 and 1000{noformat}
> In Calcite:
> {noformat}
> EXPR$0=155.36{noformat}
> 2) To make sure return the right answer。
> SQL EXAMPLES:
> {code:java}
> cast(155.36 as decimal(4,1)){code}
> In Postgresql:
> {code:java}
> EXPR$0=155.4{code}
> In Calcite:
> {code:java}
> EXPR$0=155.36{code}
> The problem exists in casting different data to decimal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4871) CAST a literal to DECIMAL type return wrong result
[
https://issues.apache.org/jira/browse/CALCITE-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459530#comment-17459530
]
duan xiong commented on CALCITE-4871:
-
Because blocked by CALCITE-4929. So I will move it to 1.30.0.
> CAST a literal to DECIMAL type return wrong result
> --
>
> Key: CALCITE-4871
> URL: https://issues.apache.org/jira/browse/CALCITE-4871
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.28.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In calcite. The precision and scale can't work.
> 1) Add judgment in decimal type precision and scale parameter(When have
> illegal value need to throw an exception):
> SQL EXAMPLES:
> {code:java}
> cast(155.36 as decimal(0,0)){code}
> In Postgresql:
> {noformat}
> ERROR: NUMERIC precision 0 must be between 1 and 1000{noformat}
> In Calcite:
> {noformat}
> EXPR$0=155.36{noformat}
> 2) To make sure return the right answer。
> SQL EXAMPLES:
> {code:java}
> cast(155.36 as decimal(4,1)){code}
> In Postgresql:
> {code:java}
> EXPR$0=155.4{code}
> In Calcite:
> {code:java}
> EXPR$0=155.36{code}
> The problem exists in casting different data to decimal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong resolved CALCITE-4906.
-
Resolution: Fixed
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong reassigned CALCITE-4906:
---
Assignee: Aleksey Plekhanov (was: duan xiong)
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459527#comment-17459527
]
duan xiong commented on CALCITE-4906:
-
Fixed in
[250dfb7a|https://github.com/apache/calcite/commit/250dfb7a378fd4f8068b63fc9defde8995bbd9a7].
Thanks for your PR [~alex_pl] .
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong reassigned CALCITE-4906:
---
Assignee: duan xiong (was: Aleksey Plekhanov)
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4927) Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList) clashing with new replacement API
[
https://issues.apache.org/jira/browse/CALCITE-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4927.
---
Resolution: Fixed
> Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList)
> clashing with new replacement API
> ---
>
> Key: CALCITE-4927
> URL: https://issues.apache.org/jira/browse/CALCITE-4927
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.28.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{RelBuilder#groupKey(ImmutableBitSet, ImmutableList)}} API is marked for
> removal before 2.0.
> {code:java}
> /** @deprecated Use {@link #groupKey(ImmutableBitSet)}
>* or {@link #groupKey(ImmutableBitSet, Iterable)}. */
> @Deprecated // to be removed before 2.0
> public GroupKey groupKey(ImmutableBitSet groupSet,
> @Nullable ImmutableList groupSets)
> {code}
> I would suggest to remove it ASAP due to the fact that it clashes with the
> new replacement API.
> {code:java}
> public GroupKey groupKey(ImmutableBitSet groupSet,
> Iterable groupSets)
> {code}
> Leaving it as is creates ambiguity and requires everybody to upcast to
> {{Iterable}} if they want to use the new API.
> Removing it on the other hand does not seem to affect much backward
> compatibility since callers will automatically use the new API with no
> changes required in their code.
> The main difference is that the deprecated API allows {{groupSets}} to be
> null but if we care so much we can also make the new API to be more
> permissive.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4941) SemiJoinRule loses hints
[ https://issues.apache.org/jira/browse/CALCITE-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4941: Labels: pull-request-available (was: ) > SemiJoinRule loses hints > > > Key: CALCITE-4941 > URL: https://issues.apache.org/jira/browse/CALCITE-4941 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.28.0 >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > SemiJoinRule does not propagate the (potential) hints from the input Join to > the output SemiJoin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4941) SemiJoinRule loses hints
Ruben Q L created CALCITE-4941: -- Summary: SemiJoinRule loses hints Key: CALCITE-4941 URL: https://issues.apache.org/jira/browse/CALCITE-4941 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.28.0 Reporter: Ruben Q L Assignee: Ruben Q L Fix For: 1.29.0 SemiJoinRule does not propagate the (potential) hints from the input Join to the output SemiJoin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4936) Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4936:
Labels: pull-request-available (was: )
> Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
> -
>
> Key: CALCITE-4936
> URL: https://issues.apache.org/jira/browse/CALCITE-4936
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Maksim Gramin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule strictly
> dependent on LogicalCalc class (e.g. casting call.rel to LogicalCalc, using
> LogicalCalc.create method and etc). I suggest making them more generalized
> (like CalcMergeRule) and use only Project, Filter and Calc interfaces, which
> will expand the range of their applying.
> Concrete:
> 1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
> {code:java}
> @Override public void onMatch(RelOptRuleCall call) {
> final Filter filter = call.rel(0);
> final Calc calc = call.rel(1);{code}
>
> 2. In FilterCalcMergeRule and FilterCalcMergeRule replace LogicalCalc.create
> with calc.copy:
> {code:java}
> final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
> mergedProgram);{code}
>
> 3. In ProjectCalcMergeRule replace the code:
> {code:java}
> if (RexOver.containsOver(program)) {
> LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
> call.transformTo(projectAsCalc);
> return;
> }{code}
> with a simple one:
> {code:java}
> if (RexOver.containsOver(program)) {
> return;
> }{code}
> because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4939) Upgrade log4j2 version to 2.16.0
[ https://issues.apache.org/jira/browse/CALCITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-4939. -- Resolution: Fixed Fixed in [f5a652693368ec35388b71f7c8e32ecdebd1558d|https://github.com/apache/calcite/commit/f5a652693368ec35388b71f7c8e32ecdebd1558d]. Thanks for the reviews [~asolimando], [~rubenql], @guiyanakuang! > Upgrade log4j2 version to 2.16.0 > > > Key: CALCITE-4939 > URL: https://issues.apache.org/jira/browse/CALCITE-4939 > Project: Calcite > Issue Type: Improvement >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The [2.16.0 > release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has > two additional fixes related to CVE-2021-4422 for hardening security. Calcite > uses Log4j2 only for testing purposes so the risk is minimal but it would be > good to have them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4940) Upgrade log4j2 version to 2.16.0 in Avatica
[ https://issues.apache.org/jira/browse/CALCITE-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-4940. -- Resolution: Fixed Fixed in [35554749efa0268d176419e43600fb2d23a7de76|https://github.com/apache/calcite-avatica/commit/35554749efa0268d176419e43600fb2d23a7de76]. Thanks for the review [~asolimando] ! > Upgrade log4j2 version to 2.16.0 in Avatica > --- > > Key: CALCITE-4940 > URL: https://issues.apache.org/jira/browse/CALCITE-4940 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The [2.16.0 > release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has > two additional fixes related to CVE-2021-4422 for hardening security. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4939) Upgrade log4j2 version to 2.16.0
[ https://issues.apache.org/jira/browse/CALCITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4939: Labels: pull-request-available (was: ) > Upgrade log4j2 version to 2.16.0 > > > Key: CALCITE-4939 > URL: https://issues.apache.org/jira/browse/CALCITE-4939 > Project: Calcite > Issue Type: Improvement >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The [2.16.0 > release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has > two additional fixes related to CVE-2021-4422 for hardening security. Calcite > uses Log4j2 only for testing purposes so the risk is minimal but it would be > good to have them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4940) Upgrade log4j2 version to 2.16.0 in Avatica
Stamatis Zampetakis created CALCITE-4940: Summary: Upgrade log4j2 version to 2.16.0 in Avatica Key: CALCITE-4940 URL: https://issues.apache.org/jira/browse/CALCITE-4940 Project: Calcite Issue Type: Improvement Components: avatica Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis Fix For: avatica-1.21.0 The [2.16.0 release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has two additional fixes related to CVE-2021-4422 for hardening security. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4939) Upgrade log4j2 version to 2.16.0
Stamatis Zampetakis created CALCITE-4939: Summary: Upgrade log4j2 version to 2.16.0 Key: CALCITE-4939 URL: https://issues.apache.org/jira/browse/CALCITE-4939 Project: Calcite Issue Type: Improvement Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis Fix For: 1.29.0 The [2.16.0 release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has two additional fixes related to CVE-2021-4422 for hardening security. Calcite uses Log4j2 only for testing purposes so the risk is minimal but it would be good to have them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
