[jira] [Updated] (CALCITE-5223) AdjustProjectForCountAggregateRule throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CALCITE-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5223:
Labels: pull-request-available (was: )
> AdjustProjectForCountAggregateRule throws ArrayIndexOutOfBoundsException
>
>
> Key: CALCITE-5223
> URL: https://issues.apache.org/jira/browse/CALCITE-5223
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While decorrelating a query with a scalar sub-query,
> AdjustProjectForCountAggregateRule throws ArrayIndexOutOfBoundsException.
> Here is an example (also in attached PR).
> {noformat}
> ./sqlline
> !connect jdbc:calcite:model=core/src/test/resources/hsqldb-model.json sa sa
> SELECT deptno, ename, job, sal,
> sal / (SELECT SUM(sal) FROM Emp WHERE deptno = e.deptno) AS pct_dept,
> sal / (SELECT SUM(sal) FROM Emp) AS pct_total
> FROM Emp AS e
> WHERE job = 'CLERK'
> ORDER BY deptno;
> java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 6
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:77)
> at org.apache.calcite.rex.RexBuilder.makeInputRef(RexBuilder.java:911)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.lambda$onMatch2$4(RelDecorrelator.java:2673)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.onMatch2(RelDecorrelator.java:2674)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.onMatch(RelDecorrelator.java:2604)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeRuleInstance(HepPlanner.java:243)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance$State.execute(HepInstruction.java:178)
> at
> org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
> at
> com.google.common.collect.ImmutableList.forEach(ImmutableList.java:422)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
> at
> org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelate(RelDecorrelator.java:291)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:230)
> at
> org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:648)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:677)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> {noformat}
--
This message was sent b
[jira] [Created] (CALCITE-5223) AdjustProjectForCountAggregateRule throws ArrayIndexOutOfBoundsException
Julian Hyde created CALCITE-5223:
Summary: AdjustProjectForCountAggregateRule throws
ArrayIndexOutOfBoundsException
Key: CALCITE-5223
URL: https://issues.apache.org/jira/browse/CALCITE-5223
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
While decorrelating a query with a scalar sub-query,
AdjustProjectForCountAggregateRule throws ArrayIndexOutOfBoundsException. Here
is an example (also in attached PR).
{noformat}
./sqlline
!connect jdbc:calcite:model=core/src/test/resources/hsqldb-model.json sa sa
SELECT deptno, ename, job, sal,
sal / (SELECT SUM(sal) FROM Emp WHERE deptno = e.deptno) AS pct_dept,
sal / (SELECT SUM(sal) FROM Emp) AS pct_total
FROM Emp AS e
WHERE job = 'CLERK'
ORDER BY deptno;
java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 6
at
com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:77)
at org.apache.calcite.rex.RexBuilder.makeInputRef(RexBuilder.java:911)
at
org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.lambda$onMatch2$4(RelDecorrelator.java:2673)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at
org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.onMatch2(RelDecorrelator.java:2674)
at
org.apache.calcite.sql2rel.RelDecorrelator$AdjustProjectForCountAggregateRule.onMatch(RelDecorrelator.java:2604)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420)
at
org.apache.calcite.plan.hep.HepPlanner.executeRuleInstance(HepPlanner.java:243)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance$State.execute(HepInstruction.java:178)
at
org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
at
com.google.common.collect.ImmutableList.forEach(ImmutableList.java:422)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
at
org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191)
at
org.apache.calcite.sql2rel.RelDecorrelator.decorrelate(RelDecorrelator.java:291)
at
org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:230)
at
org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
at
org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:648)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:677)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572696#comment-17572696
]
Julian Hyde commented on CALCITE-5222:
--
I believe that CALCITE-5143, which is linked to CALCITE-5155, handles most or
all of the parser aspects.
> Support more EXTRACT field values (or allow arbitrary in parse?)
>
>
> Key: CALCITE-5222
> URL: https://issues.apache.org/jira/browse/CALCITE-5222
> Project: Calcite
> Issue Type: Improvement
>Reporter: Steven Talbot
>Priority: Major
>
> E.g. a number of BigQuery EXTRACTs from
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#extract]
> do not parse with the babel parser
> {noformat}
> EXTRACT(DAYOFWEEK FROM )
> EXTRACT(TIME FROM ){noformat}
> (also DATE, DATETIME, DAYOFYEAR... there may be others)
> Other dialects may have similar problems, e.g. "EXTRACT(JULIAN...)" in
> Postgres looks like it wouldn't parse either.
> Calcite chasing down every value ever implemented by a DB vendor here seems
> like it might be too tall of a task, but perhaps allowing for an arbitrary
> keyword in that syntactic position, and then users of the parser would have
> to handle it if the parse of the EXTRACT comes out with an arbitrary symbol,
> rather than a TimeUnit enum value for one of the known EXTRACT fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572695#comment-17572695
]
Steven Talbot commented on CALCITE-5222:
^^ probably, sorry for missing that, though this would be a good reminder to
make it work in the parser as well, if that other issue doesn't cover the
parser.
> Support more EXTRACT field values (or allow arbitrary in parse?)
>
>
> Key: CALCITE-5222
> URL: https://issues.apache.org/jira/browse/CALCITE-5222
> Project: Calcite
> Issue Type: Improvement
>Reporter: Steven Talbot
>Priority: Major
>
> E.g. a number of BigQuery EXTRACTs from
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#extract]
> do not parse with the babel parser
> {noformat}
> EXTRACT(DAYOFWEEK FROM )
> EXTRACT(TIME FROM ){noformat}
> (also DATE, DATETIME, DAYOFYEAR... there may be others)
> Other dialects may have similar problems, e.g. "EXTRACT(JULIAN...)" in
> Postgres looks like it wouldn't parse either.
> Calcite chasing down every value ever implemented by a DB vendor here seems
> like it might be too tall of a task, but perhaps allowing for an arbitrary
> keyword in that syntactic position, and then users of the parser would have
> to handle it if the parse of the EXTRACT comes out with an arbitrary symbol,
> rather than a TimeUnit enum value for one of the known EXTRACT fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572660#comment-17572660
]
Julian Hyde commented on CALCITE-5222:
--
Duplicate of CALCITE-5155, I think.
> Support more EXTRACT field values (or allow arbitrary in parse?)
>
>
> Key: CALCITE-5222
> URL: https://issues.apache.org/jira/browse/CALCITE-5222
> Project: Calcite
> Issue Type: Improvement
>Reporter: Steven Talbot
>Priority: Major
>
> E.g. a number of BigQuery EXTRACTs from
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#extract]
> do not parse with the babel parser
> {noformat}
> EXTRACT(DAYOFWEEK FROM )
> EXTRACT(TIME FROM ){noformat}
> (also DATE, DATETIME, DAYOFYEAR... there may be others)
> Other dialects may have similar problems, e.g. "EXTRACT(JULIAN...)" in
> Postgres looks like it wouldn't parse either.
> Calcite chasing down every value ever implemented by a DB vendor here seems
> like it might be too tall of a task, but perhaps allowing for an arbitrary
> keyword in that syntactic position, and then users of the parser would have
> to handle it if the parse of the EXTRACT comes out with an arbitrary symbol,
> rather than a TimeUnit enum value for one of the known EXTRACT fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
Steven Talbot created CALCITE-5222:
--
Summary: Support more EXTRACT field values (or allow arbitrary in
parse?)
Key: CALCITE-5222
URL: https://issues.apache.org/jira/browse/CALCITE-5222
Project: Calcite
Issue Type: Improvement
Reporter: Steven Talbot
E.g. a number of BigQuery EXTRACTs from
[https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#extract]
do not parse with the babel parser
{noformat}
EXTRACT(DAYOFWEEK FROM )
EXTRACT(TIME FROM ){noformat}
(also DATE, DATETIME, DAYOFYEAR... there may be others)
Other dialects may have similar problems, e.g. "EXTRACT(JULIAN...)" in Postgres
looks like it wouldn't parse either.
Calcite chasing down every value ever implemented by a DB vendor here seems
like it might be too tall of a task, but perhaps allowing for an arbitrary
keyword in that syntactic position, and then users of the parser would have to
handle it if the parse of the EXTRACT comes out with an arbitrary symbol,
rather than a TimeUnit enum value for one of the known EXTRACT fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5212) Attempting to create a Decimal with scale specified but precision not specified results in Decimal with scale 0
[
https://issues.apache.org/jira/browse/CALCITE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572505#comment-17572505
]
Stamatis Zampetakis commented on CALCITE-5212:
--
If I understand well the problem, you somehow managed to create a DECIMAL(0,
5). Most DBMS systems raise an error/exception when the user attempts to create
a type with zero precision.
{noformat}
postgres=# CREATE TABLE dec_table_test (dec_col DECIMAL(0,5));
ERROR: NUMERIC precision 0 must be between 1 and 1000
LINE 1: CREATE TABLE dec_table_test (dec_col DECIMAL(0,5));
{noformat}
All in all, I believe this is a bug that should be fixed but not really have
time to work on this myself.
> Attempting to create a Decimal with scale specified but precision not
> specified results in Decimal with scale 0
> ---
>
> Key: CALCITE-5212
> URL: https://issues.apache.org/jira/browse/CALCITE-5212
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.30.0
>Reporter: Ian Bertolacci
>Priority: Minor
>
> (Frankly, I'm not sure if there is really any need to change this behavior,
> as scale without precision is a very odd case that doesn't really make a lot
> of sense in the larger picture (the system we're building on top of uses
> precision to mean digits _before_ the decimal-point and not the total number
> of digits, and we're still playing around with if and how that should be
> expressed in Calcite's type-system), but I'm still writing this out anyways
> just in-case it is of interest to anyone or if someone else encounters this
> behavior and want's an explanation.)
>
> {{`RelDataTypeFactoryImpl.createSqlType(SqlTypeName.DECIMAL,
> RelDataType.PRECISION_NOT_SPECIFIED, 5)`}} could be expected to create a
> Decimal with scale 5.
> However it instead creates a Decimal with scale 0.†
> This happens because:
> # RelDataType does not include scale in its digest if precision is not
> specified.
> Thus: Two Decimal types with different scales but no precision have *the
> same* digest.
> # RelDataType uses the digest to compute a hash code.
> Thus: Two Decimal types with different scales but no precision have *the
> same* hash code.
> # {{`RelDataTypeFactoryImpl.canonize(RelDataType)`}} is used to look up a
> type in {{`DATATYPE_CACHE`}} which uses the hash code as the key.
> Thus: Two Decimal types with different scales but no precision *will collide*
> in the cache.
> # There is no check in RelDataTypeFactoryImpl or SqlTypeFactoryImpl's
> canonize method to assert that the type returned from the cache actually
> matches the type given as a parameter.
> Thus: If the parameter type matches a type in the cache, the cache'd type
> will *always* be returned, even if it the two types are different.
> # RelDataTypeFactoryImpl and its child classes (such as SqlTypeFactoryImpl)
> all use the result canonize *at the end* of the type creation functions (such
> as createSqlType) as the result of the function.
> Thus: If the function creates an intermediate Decimal type with scale but no
> precision, the result of the function will be whatever that intermediate type
> matches with in the cache, which could have any scale.
> † I think it might actually be possible for a scale other than zero to be
> returned if a Decimal with non-zero scale and unspecified precision has been
> created before the Decimal with zero scale and unspecified precision has been
> created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5217) Implement unparseSqlIntervalLiteral in the Firebolt dialect
[
https://issues.apache.org/jira/browse/CALCITE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis reassigned CALCITE-5217:
Assignee: Aymeric Dispa
> Implement unparseSqlIntervalLiteral in the Firebolt dialect
> ---
>
> Key: CALCITE-5217
> URL: https://issues.apache.org/jira/browse/CALCITE-5217
> Project: Calcite
> Issue Type: Bug
>Reporter: Aymeric Dispa
>Assignee: Aymeric Dispa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The syntax used by Firebolt for the operator INTERVAL does not match with the
> query generated. To fix it, the method unparseSqlIntervalLiteral must be
> implemented in the dialect.
> What we get with the current dialect:
> {code:java}
> + INTERVAL '1' DAY {code}
>
> Format supported by Firebolt
> {code:java}
> + INTERVAL '1 DAY' {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
[ https://issues.apache.org/jira/browse/CALCITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5221: Labels: pull-request-available (was: ) > Upgrade Calcite to Avatica 1.22 > --- > > Key: CALCITE-5221 > URL: https://issues.apache.org/jira/browse/CALCITE-5221 > Project: Calcite > Issue Type: Task >Reporter: Ruben Q L >Assignee: Stamatis Zampetakis >Priority: Blocker > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade Calcite to Avatica 1.22, which includes the vulnerability fix in > CALCITE-5218. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
[ https://issues.apache.org/jira/browse/CALCITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis resolved CALCITE-5221. -- Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/657a3d352ff81ef54f2bc0be6884363b49741305. > Upgrade Calcite to Avatica 1.22 > --- > > Key: CALCITE-5221 > URL: https://issues.apache.org/jira/browse/CALCITE-5221 > Project: Calcite > Issue Type: Task >Reporter: Ruben Q L >Assignee: Stamatis Zampetakis >Priority: Blocker > Fix For: 1.31.0 > > > Upgrade Calcite to Avatica 1.22, which includes the vulnerability fix in > CALCITE-5218. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
[ https://issues.apache.org/jira/browse/CALCITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5221: - Description: Upgrade Calcite to Avatica 1.22, which includes the vulnerability fix in CALCITE-5218. (was: Upgrade Calcite to Avatica 1.22, which includes a vulnerability fix.) > Upgrade Calcite to Avatica 1.22 > --- > > Key: CALCITE-5221 > URL: https://issues.apache.org/jira/browse/CALCITE-5221 > Project: Calcite > Issue Type: Task >Reporter: Ruben Q L >Assignee: Stamatis Zampetakis >Priority: Blocker > Fix For: 1.31.0 > > > Upgrade Calcite to Avatica 1.22, which includes the vulnerability fix in > CALCITE-5218. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
[ https://issues.apache.org/jira/browse/CALCITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572417#comment-17572417 ] Stamatis Zampetakis commented on CALCITE-5221: -- PR is ready, I will merge this when all tests run. > Upgrade Calcite to Avatica 1.22 > --- > > Key: CALCITE-5221 > URL: https://issues.apache.org/jira/browse/CALCITE-5221 > Project: Calcite > Issue Type: Task >Reporter: Ruben Q L >Assignee: Stamatis Zampetakis >Priority: Blocker > Fix For: 1.31.0 > > > Upgrade Calcite to Avatica 1.22, which includes a vulnerability fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
[ https://issues.apache.org/jira/browse/CALCITE-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis reassigned CALCITE-5221: Assignee: Stamatis Zampetakis > Upgrade Calcite to Avatica 1.22 > --- > > Key: CALCITE-5221 > URL: https://issues.apache.org/jira/browse/CALCITE-5221 > Project: Calcite > Issue Type: Task >Reporter: Ruben Q L >Assignee: Stamatis Zampetakis >Priority: Blocker > Fix For: 1.31.0 > > > Upgrade Calcite to Avatica 1.22, which includes a vulnerability fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5221) Upgrade Calcite to Avatica 1.22
Ruben Q L created CALCITE-5221: -- Summary: Upgrade Calcite to Avatica 1.22 Key: CALCITE-5221 URL: https://issues.apache.org/jira/browse/CALCITE-5221 Project: Calcite Issue Type: Task Reporter: Ruben Q L Fix For: 1.31.0 Upgrade Calcite to Avatica 1.22, which includes a vulnerability fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5218) Verify HTTP client class before instantiating it
[ https://issues.apache.org/jira/browse/CALCITE-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572288#comment-17572288 ] Ruben Q L commented on CALCITE-5218: CVE-2022-36364: Apache Calcite Avatica JDBC driver `httpclient_impl` connection property can be used as an RCE vector Severity: moderate Description: Apache Calcite Avatica JDBC driver creates HTTP client instances based on class names provided via `httpclient_impl` connection property; however, the driver does not verify if the class implements the expected interface before instantiating it, which can lead to code execution loaded via arbitrary classes and in rare cases remote code execution. To exploit the vulnerability: 1) the attacker needs to have privileges to control JDBC connection parameters; 2) and there should be a vulnerable class (constructor with URL parameter and ability to execute code) in the classpath. >From Apache Calcite Avatica 1.22.0 onwards, it will be verified that the class >implements the expected interface before invoking its constructor. Credit: Apache Calcite Avatica would like to thank Peter M (https://twitter.com/h1pmnh) for reporting this issue > Verify HTTP client class before instantiating it > - > > Key: CALCITE-5218 > URL: https://issues.apache.org/jira/browse/CALCITE-5218 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Fix For: avatica-1.22.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Verify HTTP client class before instantiating it -- This message was sent by Atlassian Jira (v8.20.10#820010)
