[jira] [Updated] (CALCITE-6622) Negative logarithms should throw an ArithmeticException, not an IllegalArgumentException
[
https://issues.apache.org/jira/browse/CALCITE-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated CALCITE-6622:
Description:
Since |CALCITE-6312], {{log}} functions in {{SqlFunctions}} do throw an
{{{}IllegalArgumentException{}}}, instead as an {{ArithmeticException}} as
before.
In terms of errors categorization, it is more precise to revert to the former
behavior, as {{IllegalArgumentException}} is more suited to structural errors
which do not depend on the actual values, whereas we would expect negative
logarithms to throw the same kind of error as an integer division by zero for
instance.
An engine implementation could choose to have a different behaviors depending
on the thrown errors, for instance to just abort the constants reduction for an
illegal argument versus letting the arithmetic exception propagate to alert the
user.
was:
Since |CALCITE-6312], {{log}} functions in {{SqlFunctions}} do throw an
{{{}IllegalArgumentException{}}}, instead as an {{ArithmeticException}} as
before.
In terms of errors categorization, it is more precise to revert to the former
behavior, as {{IllegalArgumentException}} is more suited to structural errors
which do not depend on the actual values, whereas we would expect negative
algorithms to throw the same kind of error as an integer division by zero for
instance.
An engine implementation could choose to have a different behaviors depending
on the thrown errors, for instance to just abort the constants reduction for an
illegal argument versus letting the arithmetic exception propagate to alert the
user.
> Negative logarithms should throw an ArithmeticException, not an
> IllegalArgumentException
>
>
> Key: CALCITE-6622
> URL: https://issues.apache.org/jira/browse/CALCITE-6622
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.38.0
>Reporter: Claude Brisson
>Priority: Minor
>
> Since |CALCITE-6312], {{log}} functions in {{SqlFunctions}} do throw an
> {{{}IllegalArgumentException{}}}, instead as an {{ArithmeticException}} as
> before.
> In terms of errors categorization, it is more precise to revert to the former
> behavior, as {{IllegalArgumentException}} is more suited to structural errors
> which do not depend on the actual values, whereas we would expect negative
> logarithms to throw the same kind of error as an integer division by zero for
> instance.
> An engine implementation could choose to have a different behaviors depending
> on the thrown errors, for instance to just abort the constants reduction for
> an illegal argument versus letting the arithmetic exception propagate to
> alert the user.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6622) Negative logarithms should throw an ArithmeticException, not an IllegalArgumentException
[
https://issues.apache.org/jira/browse/CALCITE-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated CALCITE-6622:
Summary: Negative logarithms should throw an ArithmeticException, not an
IllegalArgumentException (was: Negative algorithms should throw an
ArithmeticException, not an IllegalArgumentException)
> Negative logarithms should throw an ArithmeticException, not an
> IllegalArgumentException
>
>
> Key: CALCITE-6622
> URL: https://issues.apache.org/jira/browse/CALCITE-6622
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.38.0
>Reporter: Claude Brisson
>Priority: Minor
>
> Since |CALCITE-6312], {{log}} functions in {{SqlFunctions}} do throw an
> {{{}IllegalArgumentException{}}}, instead as an {{ArithmeticException}} as
> before.
> In terms of errors categorization, it is more precise to revert to the former
> behavior, as {{IllegalArgumentException}} is more suited to structural errors
> which do not depend on the actual values, whereas we would expect negative
> algorithms to throw the same kind of error as an integer division by zero for
> instance.
> An engine implementation could choose to have a different behaviors depending
> on the thrown errors, for instance to just abort the constants reduction for
> an illegal argument versus letting the arithmetic exception propagate to
> alert the user.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6622) Negative algorithms should throw an ArithmeticException, not an IllegalArgumentException
Claude Brisson created CALCITE-6622:
---
Summary: Negative algorithms should throw an ArithmeticException,
not an IllegalArgumentException
Key: CALCITE-6622
URL: https://issues.apache.org/jira/browse/CALCITE-6622
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.38.0
Reporter: Claude Brisson
Since |CALCITE-6312], {{log}} functions in {{SqlFunctions}} do throw an
{{{}IllegalArgumentException{}}}, instead as an {{ArithmeticException}} as
before.
In terms of errors categorization, it is more precise to revert to the former
behavior, as {{IllegalArgumentException}} is more suited to structural errors
which do not depend on the actual values, whereas we would expect negative
algorithms to throw the same kind of error as an integer division by zero for
instance.
An engine implementation could choose to have a different behaviors depending
on the thrown errors, for instance to just abort the constants reduction for an
illegal argument versus letting the arithmetic exception propagate to alert the
user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6621) RexBuilder.makeOver() should not try to nullify a null result
Claude Brisson created CALCITE-6621:
---
Summary: RexBuilder.makeOver() should not try to nullify a null
result
Key: CALCITE-6621
URL: https://issues.apache.org/jira/browse/CALCITE-6621
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.38.0
Reporter: Claude Brisson
This is probably linked to CALCITE-6020.
In a window function that uses the nullable {{SUM}} aggregation operator,
{{RexBuilder.makeOver()}} will produce the following construct:
{code:java}
CASE((COUNT($0) OVER (...), 0), SUM($0) OVER (...), null:BIGINT) {code}
which is both useless and inefficient.
Using this construct should only be done for non-nullable aggregation operators
like {{SUM0}} (that's the only one I can think of).
The workaround is to inherit {{RexBuilder}} and override {{makeOver() }}as
follow:
{code:java}
public RexNode makeOver(
RelDataType type,
SqlAggFunction operator,
List exprs,
List partitionKeys,
ImmutableList orderKeys,
RexWindowBound lowerBound,
RexWindowBound upperBound,
RexWindowExclusion exclude,
boolean rows,
boolean allowPartial,
boolean nullWhenCountZero,
boolean distinct,
boolean ignoreNulls) {
return super.makeOver(
type,
operator,
exprs,
partitionKeys,
orderKeys,
lowerBound,
upperBound,
exclude,
rows,
allowPartial,
nullWhenCountZero && operator.getKind() == SqlKind.SUM0,
distinct,
ignoreNulls
);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6617) Regression after CALCITE-2067 which gives a ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887381#comment-17887381
]
Claude Brisson commented on CALCITE-6617:
-
I found another place that has the same problem, during rex expressions
simplification: for the query below, the ReduceExpressionsRule optimizer builds
a tree map of ranges, and tries to insert into it both BigDecimals and Doubles,
leading to a ClassCastException.
{code:java}
SELECT * FROM (SELECT 1 ROUND(RANDOM()) AS A) WHERE A BETWEEN 1 AND 10 OR A
IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) {code}
Stack trace:
{code:java}
java.lang.ClassCastException: class java.math.BigDecimal cannot be cast to
class java.lang.Double (java.math.BigDecimal and java.lang.Double are in module
java.base of loader 'bootstrap')
at java.base/java.lang.Double.compareTo(Double.java:360)
at com.google.common.collect.Range.compareOrThrow(Range.java:702)
at com.google.common.collect.Cut.compareTo(Cut.java:81)
at com.google.common.collect.Cut$BelowValue.compareTo(Cut.java:315)
at java.base/java.util.TreeMap.compare(TreeMap.java:1606)
at java.base/java.util.TreeMap.getLowerEntry(TreeMap.java:527)
at java.base/java.util.TreeMap.lowerEntry(TreeMap.java:1012)
at com.google.common.collect.TreeRangeSet.add(TreeRangeSet.java:191)
at
org.apache.calcite.rex.RexSimplify$RexSargBuilder.addRange(RexSimplify.java:3186)
at
org.apache.calcite.rex.RexSimplify$SargCollector.accept2b(RexSimplify.java:3034)
at
org.apache.calcite.rex.RexSimplify$SargCollector.accept2(RexSimplify.java:2960)
at
org.apache.calcite.rex.RexSimplify$SargCollector.accept_(RexSimplify.java:2941)
at
org.apache.calcite.rex.RexSimplify$SargCollector.accept(RexSimplify.java:2926)
at
org.apache.calcite.rex.RexSimplify$SargCollector.access$500(RexSimplify.java:2909)
at
org.apache.calcite.rex.RexSimplify.lambda$simplifyOrs$7(RexSimplify.java:2002)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
at org.apache.calcite.rex.RexSimplify.simplifyOrs(RexSimplify.java:2002)
at org.apache.calcite.rex.RexSimplify.simplifyOr(RexSimplify.java:1979)
at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:284)
at
org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:251)
at
org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:190)
at
org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:720)
at
org.apache.calcite.rel.rules.ReduceExpressionsRule$FilterReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:157)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:336)
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.executeEndGroup(HepPlanner.java:360)
at
org.apache.calcite.plan.hep.HepInstruction$EndGroup$State.execute(HepInstruction.java:349)
at
org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
at com.google.common.collect.ImmutableList.forEach(ImmutableList.java:423)
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)
{code}
> Regression after CALCITE-2067 which gives a ClassCastException
> --
>
> Key: CALCITE-6617
> URL: https://issues.apache.org/jira/browse/CALCITE-6617
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Claude Brisson
>Priority: Blocker
> Fix For: 1.38.0
>
>
> The following statement:
> {code:java}
> SELECT * FROM (VALUES (1, 2, 3), (5E0::REAL, 5E0, NULL)) AS foo {code}
> will provoke a ClassCastException between a Double and a BigDecimal, while it
> was working in 1.37.0.
> It's due to the fact that when trying to infer a collation on a Values
> tuples, the comparator still assumes that all numbers are of the same class,
> which changed with CALCITE-2067.
> Here is the full stack trace:
>
> {code:java}
> Caused by: java.lang.ClassCastException: class java.lang.Double cannot be
> cast to class java.math.BigDecimal (java.lang.Double and java.math.BigDecimal
> are in module java.base of loader 'bootstrap')
> at java.base/java.math.BigDecimal.compareTo(BigDecimal.java:330)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:45)
> at
> org.apache.calcite.rel.metadata.RelMdCollation$1.compare(RelMd
[jira] [Created] (CALCITE-6617) Regression after CALCITE-2067 which gives a ClassCastException
Claude Brisson created CALCITE-6617:
---
Summary: Regression after CALCITE-2067 which gives a
ClassCastException
Key: CALCITE-6617
URL: https://issues.apache.org/jira/browse/CALCITE-6617
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.38.0
Reporter: Claude Brisson
The following statement:
{code:java}
SELECT * FROM (VALUES (1, 2, 3), (5E0::REAL, 5E0, NULL)) AS foo {code}
will provoke a ClassCastException between a Double and a BigDecimal, while it
was working in 1.37.0.
It's due to the fact that when trying to infer a collation on a Values tuples,
the comparator still assumes that all numbers are of the same class, which
changed with CALCITE-2067.
Here is the full stack trace:
{code:java}
Caused by: java.lang.ClassCastException: class java.lang.Double cannot be cast
to class java.math.BigDecimal (java.lang.Double and java.math.BigDecimal are in
module java.base of loader 'bootstrap')
at java.base/java.math.BigDecimal.compareTo(BigDecimal.java:330)
at
org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:45)
at
org.apache.calcite.rel.metadata.RelMdCollation$1.compare(RelMdCollation.java:458)
at
org.apache.calcite.rel.metadata.RelMdCollation$1.compare(RelMdCollation.java:454)
at com.google.common.collect.Ordering.isOrdered(Ordering.java:910)
at
org.apache.calcite.rel.metadata.RelMdCollation.values(RelMdCollation.java:434)
at
org.apache.calcite.rel.logical.LogicalValues.lambda$create$0(LogicalValues.java:111)
at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:246)
at
org.apache.calcite.rel.logical.LogicalValues.create(LogicalValues.java:110)
at
org.apache.calcite.rel.core.RelFactories$ValuesFactoryImpl.createValues(RelFactories.java:521)
at org.apache.calcite.tools.RelBuilder.values(RelBuilder.java:3497)
at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:2924)
at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:2946)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertValuesImpl(SqlToRelConverter.java:5050)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2488)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2393)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2355)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:754)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:734)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3905)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:627)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6594) RelMdSize does not handle ARRAY constructor calls
Claude Brisson created CALCITE-6594:
---
Summary: RelMdSize does not handle ARRAY constructor calls
Key: CALCITE-6594
URL: https://issues.apache.org/jira/browse/CALCITE-6594
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.37.0
Reporter: Claude Brisson
We would expect the method
{{RelMdSize.averageRexSize(RexNode node, List inputColumnSizes)}}
to handle an ARRAY constructor call by multiplying the array size by the
average size of its contained type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6572) Calcite TO_CHAR function is incorrectly marked as returning a non-nullable result
[
https://issues.apache.org/jira/browse/CALCITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880972#comment-17880972
]
Claude Brisson commented on CALCITE-6572:
-
Here's the log of a postgres session:
{code}
=# create temporary table t (ts timestamp);
CREATE TABLE
=# insert into t values (timestamp '2024-05-05'), (null);
INSERT 0 2
=# select to_char(ts, '') is null from t;
?column?
--
f
t
(2 rows)
{code}
And here's how the TO_CHAR is defined in SqlLibraryOperators.java :
{code}
/** The "TO_CHAR(timestamp, format)" function;
* converts \{@code timestamp} to string according to the given \{@code
format}.
*
* (\{@code TO_CHAR} is not supported in MySQL, but it is supported in
* MariaDB, a variant of MySQL covered by \{@link SqlLibrary#MYSQL}.) */
@LibraryOperator(libraries = \{MYSQL, ORACLE, POSTGRESQL})
public static final SqlFunction TO_CHAR =
SqlBasicFunction.create("TO_CHAR",
ReturnTypes.VARCHAR,
OperandTypes.TIMESTAMP_STRING,
SqlFunctionCategory.TIMEDATE);
{code}
Obviously, the return type should be {code}ReturnTypes.VARCHAR_NULLABLE{code}.
> Calcite TO_CHAR function is incorrectly marked as returning a non-nullable
> result
> -
>
> Key: CALCITE-6572
> URL: https://issues.apache.org/jira/browse/CALCITE-6572
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Claude Brisson
>Priority: Minor
>
> We would expect the result of TO_CHAR(, ) to be
> nullable, while it is not for now.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6572) Calcite TO_CHAR function is incorrectly marked as returning a non-nullable result
Claude Brisson created CALCITE-6572: --- Summary: Calcite TO_CHAR function is incorrectly marked as returning a non-nullable result Key: CALCITE-6572 URL: https://issues.apache.org/jira/browse/CALCITE-6572 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.37.0 Reporter: Claude Brisson We would expect the result of TO_CHAR(, ) to be nullable, while it is not for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6402) Aggregates implied in grouping sets have a wrong nullability at validation stage
Claude Brisson created CALCITE-6402:
---
Summary: Aggregates implied in grouping sets have a wrong
nullability at validation stage
Key: CALCITE-6402
URL: https://issues.apache.org/jira/browse/CALCITE-6402
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Claude Brisson
As long as the empty set is present among the grouping sets, which is always
the case for CUBE and ROLLAP, the (unfiltered) result will contain a row with
the global aggregate. And on such a row, most standard aggregate functions are
nullable (even on a non-null column, for the empty rowset).
But the SUM function, for instance, has the following return type inference:
{code}
public static final SqlReturnTypeInference AGG_SUM = opBinding -> {
final RelDataTypeFactory typeFactory = opBinding.getTypeFactory();
final RelDataType type = typeFactory.getTypeSystem()
.deriveSumType(typeFactory, opBinding.getOperandType(0));
if (opBinding.getGroupCount() == 0 || opBinding.hasFilter()) {
return typeFactory.createTypeWithNullability(type, true);
} else {
return type;
}
};
{code}
If the operand is not nullable, since the group count will be non-zero for a
rollup, a cube or a grouping sets containing the empty set.
It seems to me that the group count itself is not a sufficient information to
determine the nullability, we may be lacking a boolean stating whether the
empty group is implied, or the complete list of groups instead of the groups
count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5634) Enable GREATEST, LEAST functions in PostgreSQL library
[ https://issues.apache.org/jira/browse/CALCITE-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841605#comment-17841605 ] Claude Brisson commented on CALCITE-5634: - True, but whatever its name, it won't either ensure the comparability of the types, neither invoke operand types coercion, whereas ComparableOperandTypeChecker will. We'd want both for those operators. Also, GREATEST and LEAST seem absent from RexImpTable, at least in 1.36. And since UDFs cannot be variadic, the workaround is not obvious to me. > Enable GREATEST, LEAST functions in PostgreSQL library > -- > > Key: CALCITE-5634 > URL: https://issues.apache.org/jira/browse/CALCITE-5634 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Dmitry Sysolyatin >Assignee: Dmitry Sysolyatin >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The LEAST and GREATEST functions have been implemented for BigQuery and > Oracle, but haven't been added for PostgreSQL. PostgreSQL supports LEAST, > GREATEST as well [1]. > Also PostgreSQL's LEAST, GREATEST functions behave differently with NULL > values than ORACLE or BigQuery. > From PostgreSQL documentation [1]: > ??The result will be NULL only if all the expressions evaluate to NULL.?? > From BigQuery documentation [2]: > ??They return NULL if any of the input parameters is NULL.?? > [1] > [https://www.postgresql.org/docs/15/functions-conditional.html#FUNCTIONS-GREATEST-LEAST] > [2] > [https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5634) Enable GREATEST, LEAST functions in PostgreSQL library
[ https://issues.apache.org/jira/browse/CALCITE-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841440#comment-17841440 ] Claude Brisson commented on CALCITE-5634: - Related, so I add it here: for all the dialects, the operands type checker must be a ComparableOperandTypeChecker, not a SameOperandTypeChecker. > Enable GREATEST, LEAST functions in PostgreSQL library > -- > > Key: CALCITE-5634 > URL: https://issues.apache.org/jira/browse/CALCITE-5634 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.34.0 >Reporter: Dmitry Sysolyatin >Assignee: Dmitry Sysolyatin >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The LEAST and GREATEST functions have been implemented for BigQuery and > Oracle, but haven't been added for PostgreSQL. PostgreSQL supports LEAST, > GREATEST as well [1]. > Also PostgreSQL's LEAST, GREATEST functions behave differently with NULL > values than ORACLE or BigQuery. > From PostgreSQL documentation [1]: > ??The result will be NULL only if all the expressions evaluate to NULL.?? > From BigQuery documentation [2]: > ??They return NULL if any of the input parameters is NULL.?? > [1] > [https://www.postgresql.org/docs/15/functions-conditional.html#FUNCTIONS-GREATEST-LEAST] > [2] > [https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6371) Add ability to configure RexExecutable behavior on exceptions
[
https://issues.apache.org/jira/browse/CALCITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838087#comment-17838087
]
Claude Brisson commented on CALCITE-6371:
-
We're speaking about literals, here. A perfectly legitimate policy can be to
consider {{1/0}} as an invalid literal, and to refuse to process a query
containing it, even if its evaluation can somehow be evicted down the line.
> Add ability to configure RexExecutable behavior on exceptions
> -
>
> Key: CALCITE-6371
> URL: https://issues.apache.org/jira/browse/CALCITE-6371
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Priority: Major
>
> The current behavior of Calcite's {{RexExecutable}} constant folding class is
> to eat all exceptions encountered during reduction. The underlying reason, as
> far as I understand it, is that even if Calcite can't reduce an expression,
> maybe the evaluation engine will be able to do it. Fair enough.
> But it would be useful to be able to chose to let some exceptions go through.
> One good example is {{ArithmeticException}} errors. They occur on divisions
> by zero, negative logarithms, etc. and we may want to avoid the downstream
> evaluation engine to receive such invalid expressions.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6371) Add ability to configure RexExecutable behavior on exceptions
Claude Brisson created CALCITE-6371:
---
Summary: Add ability to configure RexExecutable behavior on
exceptions
Key: CALCITE-6371
URL: https://issues.apache.org/jira/browse/CALCITE-6371
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.36.0
Reporter: Claude Brisson
The current behavior of Calcite's {{RexExecutable}} constant folding class is
to eat all exceptions encountered during reduction. The underlying reason, as
far as I understand it, is that even if Calcite can't reduce an expression,
maybe the evaluation engine will be able to do it. Fair enough.
But it would be useful to be able to chose to let some exceptions go through.
One good example is {{ArithmeticException}} errors. They occur on divisions by
zero, negative logarithms, etc. and we may want to avoid the downstream
evaluation engine to receive such invalid expressions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6370) AS operator problems with USING clause
Claude Brisson created CALCITE-6370:
---
Summary: AS operator problems with USING clause
Key: CALCITE-6370
URL: https://issues.apache.org/jira/browse/CALCITE-6370
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Claude Brisson
In some cases, with the {{USING}} clause, the used column generates ambiguity
exceptions with the {{AS}} operator.
OK : {{select r_regionkey from region r0 join region r1 using (r_regionkey)}}
OK : {{select r_regionkey * 2 as rk2 from region r0 join region r1 using
(r_regionkey)}}
KO : {{select r_regionkey as rk from region r0 join region r1 using
(r_regionkey)}}
The last query generates the following error:
{code:java}
org.apache.calcite.sql.validate.SqlValidatorException: Column 'r_regionkey' is
ambiguous
at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance
(DirectConstructorHandleAccessor.java:62)
at java.lang.reflect.Constructor.newInstanceWithCaller
(Constructor.java:502)
at java.lang.reflect.Constructor.newInstance (Constructor.java:486)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex
(Resources.java:507)
at org.apache.calcite.runtime.Resources$ExInst.ex (Resources.java:601)
at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:948)
at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:933)
at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError
(SqlValidatorImpl.java:5517)
at org.apache.calcite.sql.validate.DelegatingScope.fullyQualify
(DelegatingScope.java:296)
at org.apache.calcite.sql.validate.SqlValidatorImpl.findTableColumnPair
(SqlValidatorImpl.java:3989)
at org.apache.calcite.sql.validate.SqlValidatorImpl.isRolledUpColumn
(SqlValidatorImpl.java:4032)
at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
(SqlValidatorImpl.java:3945)
at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
(SqlValidatorImpl.java:3940)
at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
(SqlValidatorImpl.java:3959)
at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUpInSelectList
(SqlValidatorImpl.java:3861)
at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
(SqlValidatorImpl.java:3849)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6369) Expanding "start" gives ArrayIndexOutOfBoundsException with redundant columns and USING
Claude Brisson created CALCITE-6369:
---
Summary: Expanding "start" gives ArrayIndexOutOfBoundsException
with redundant columns and USING
Key: CALCITE-6369
URL: https://issues.apache.org/jira/browse/CALCITE-6369
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Claude Brisson
The query
{code}
select r_regionkey, * from region r0 join region r1 using (r_regionkey)
{code}
produces
{code}
java.lang.ArrayIndexOutOfBoundsException: Index 14 out of bounds for length 14
at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
(PairLists.java:573)
at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
(PairLists.java:550)
at org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute
(SqlValidatorImpl.java:7443)
at org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar
(SqlValidatorImpl.java:697)
at org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem
(SqlValidatorImpl.java:453)
at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList
(SqlValidatorImpl.java:4658)
at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
(SqlValidatorImpl.java:3840)
at org.apache.calcite.sql.validate.SelectNamespace.validateImpl
(SelectNamespace.java:61)
at org.apache.calcite.sql.validate.AbstractNamespace.validate
(AbstractNamespace.java:88)
at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace
(SqlValidatorImpl.java:1154)
at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery
(SqlValidatorImpl.java:1125)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6368) Inconsistent handling of COALESCE during validation
Claude Brisson created CALCITE-6368:
---
Summary: Inconsistent handling of COALESCE during validation
Key: CALCITE-6368
URL: https://issues.apache.org/jira/browse/CALCITE-6368
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Claude Brisson
{{SqlCoalesceFunction}} has a {{rewriteCall()}} method which will replace the
call with an {{SqlCase}} call during the unconditional rewrites stage.
But expanding natural joins and {{USING}} conditions is done using {{COALESCE}}
calls in a later validation stage.
As a result, the following query:
{code}
WITH A AS (SELECT 1 AS X)
SELECT
COALESCE(A0.X, A1.X),
*
FROM A AS A0 NATURAL JOIN A AS A1
{code}
is transformed by the validation step into:
{code}
WITH `A` AS (SELECT 1 AS `X`)
SELECT
CASE WHEN `A0`.`X` IS NOT NULL THEN `A0`.`X` ELSE `A1`.`X` END,
COALESCE(`A0`.`X`, `A1`.`X` AS `X0`) AS `X`
FROM `A` AS `A0` NATURAL INNER JOIN `A` AS `A1`
{code}
Maybe, the expanded results of {{*}} with natural joins and of {{USING}} should
pass through unconditional rewrites at creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6327) getValidatedNodeTypeIfKnown should never throw
Claude Brisson created CALCITE-6327: --- Summary: getValidatedNodeTypeIfKnown should never throw Key: CALCITE-6327 URL: https://issues.apache.org/jira/browse/CALCITE-6327 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.36.0 Reporter: Claude Brisson During validation, when a SqlNode has been rewritten (for instance when a COALESCE call has been rewritten as a CASE call) but does not yet have a RelDataType, the method SqlValidatorImpl.getValidatedNodeTypeIfKnown() throws an exception because it relies on SqlValidatorImpl.getValidatedNodeType(originalExpr), not on SqlValidatorImpl.getValidatedNodeTypeIfKnown(originalExpr). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6144) JoinInfo is not aware of the IS NOT DISTINCT FROM operator
Claude Brisson created CALCITE-6144: --- Summary: JoinInfo is not aware of the IS NOT DISTINCT FROM operator Key: CALCITE-6144 URL: https://issues.apache.org/jira/browse/CALCITE-6144 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.35.0 Reporter: Claude Brisson A join equi-condition can use either EQUALS or IS NOT DISTINCT FROM operator to compare key columns. The JoinInfo class looses this information, and the method JoinInfo.getEquiCondition() always generate a conjunction of equalities, which is erroneous if some of the conditions were initially using IS NOT DISTINCT FROM. The JoinInfo class would need to store a vector of booleans (indicating the nulls comparison mode for each key pair) to be able to re-generate the full equi-condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763346#comment-17763346 ] Claude Brisson commented on CALCITE-5931: - Thanks for taking over the winagg.iq test. Code looks fine to me. > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5949) RexExecutable correct handling of invalid constant expressions
[
https://issues.apache.org/jira/browse/CALCITE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758147#comment-17758147
]
Claude Brisson commented on CALCITE-5949:
-
Summary updated.
> RexExecutable correct handling of invalid constant expressions
> --
>
> Key: CALCITE-5949
> URL: https://issues.apache.org/jira/browse/CALCITE-5949
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Claude Brisson
>Priority: Major
> Labels: pull-request-available
>
> While reducing, when encountering an invalid expression in the list of
> constant expressions, RexExecutor is meant to return all initial expressions
> unchanged.
> It fails to do so, because already handled correct expressions have already
> been added to the returned list, which can be greater than the input list.
> For instance, when given the list \{ LN(2), LN(-2) }, the RexExecutor will
> output a list of length 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5949) RexExecutable correct handling of invalid constant expressions
[
https://issues.apache.org/jira/browse/CALCITE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated CALCITE-5949:
Description:
While reducing, when encountering an invalid expression in the list of constant
expressions, RexExecutor is meant to return all initial expressions unchanged.
It fails to do so, because already handled correct expressions have already
been added to the returned list, which can be greater than the input list.
For instance, when given the list \{ LN(2), LN(-2) }, the RexExecutor will
output a list of length 3.
was:
While reducing, when encountering an invalid expression in the list of constant
expressions, RexExecutor is meant to return all initial expressions unchanged.
It fails to do so, because already handled correct expressions have already
been added to the returned list, which can be greater than the input list.
> RexExecutable correct handling of invalid constant expressions
> --
>
> Key: CALCITE-5949
> URL: https://issues.apache.org/jira/browse/CALCITE-5949
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Claude Brisson
>Priority: Major
>
> While reducing, when encountering an invalid expression in the list of
> constant expressions, RexExecutor is meant to return all initial expressions
> unchanged.
> It fails to do so, because already handled correct expressions have already
> been added to the returned list, which can be greater than the input list.
> For instance, when given the list \{ LN(2), LN(-2) }, the RexExecutor will
> output a list of length 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5949) RexExecutable correct handling of invalid constant expressions
[ https://issues.apache.org/jira/browse/CALCITE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated CALCITE-5949: Summary: RexExecutable correct handling of invalid constant expressions (was: RexExecutable correct handling of invalid expressions) > RexExecutable correct handling of invalid constant expressions > -- > > Key: CALCITE-5949 > URL: https://issues.apache.org/jira/browse/CALCITE-5949 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Major > > While reducing, when encountering an invalid expression in the list of > constant expressions, RexExecutor is meant to return all initial expressions > unchanged. > It fails to do so, because already handled correct expressions have already > been added to the returned list, which can be greater than the input list. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5949) RexExecutable correct handling of invalid expressions
Claude Brisson created CALCITE-5949: --- Summary: RexExecutable correct handling of invalid expressions Key: CALCITE-5949 URL: https://issues.apache.org/jira/browse/CALCITE-5949 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.35.0 Reporter: Claude Brisson While reducing, when encountering an invalid expression in the list of constant expressions, RexExecutor is meant to return all initial expressions unchanged. It fails to do so, because already handled correct expressions have already been added to the returned list, which can be greater than the input list. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757038#comment-17757038 ] Claude Brisson commented on CALCITE-5931: - Thanks for the review. I changed the PR title, and added a unit test (only one like your second proposal, the others don't really fit in the context). > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5931) Allow integers like 1.00 in window frame
[ https://issues.apache.org/jira/browse/CALCITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated CALCITE-5931: Summary: Allow integers like 1.00 in window frame (was: Fix integral number detection) > Allow integers like 1.00 in window frame > > > Key: CALCITE-5931 > URL: https://issues.apache.org/jira/browse/CALCITE-5931 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Claude Brisson >Priority: Minor > Labels: pull-request-available > > When a number of rows is specified for a window, the code checks that the > provided literal is an integral number. > But the provided check leaves aside numbers like "1.00" (with a scale of 2, > but with trailing zeros). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5931) Fix integral number detection
Claude Brisson created CALCITE-5931: --- Summary: Fix integral number detection Key: CALCITE-5931 URL: https://issues.apache.org/jira/browse/CALCITE-5931 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.35.0 Reporter: Claude Brisson When a number of rows is specified for a window, the code checks that the provided literal is an integral number. But the provided check leaves aside numbers like "1.00" (with a scale of 2, but with trailing zeros). -- This message was sent by Atlassian Jira (v8.20.10#820010)
