[jira] [Resolved] (CALCITE-5966) Upgrade commons-dbcp2 to 2.9.0
[ https://issues.apache.org/jira/browse/CALCITE-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benchao Li resolved CALCITE-5966. - Fix Version/s: 1.36.0 Resolution: Fixed Merged via [https://github.com/apache/calcite/commit/2bf1e7b2e8596a61b5ac19aa7bebb9910c4eea94] [~shoothzj] thanks for your contribution! > Upgrade commons-dbcp2 to 2.9.0 > -- > > Key: CALCITE-5966 > URL: https://issues.apache.org/jira/browse/CALCITE-5966 > Project: Calcite > Issue Type: Task >Reporter: ZhangJian He >Assignee: ZhangJian He >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > Upgrade commons-dbcp2 from 2.6.0 to 2.9.0. 2.6.0 version was released in > 2019. Regular update. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-4189) Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
[
https://issues.apache.org/jira/browse/CALCITE-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760131#comment-17760131
]
Julian Hyde commented on CALCITE-4189:
--
No, I think we should do this rewrite the traditional way.
Simplifications by exhaustively iterating possible values (booleans, or numbers
constrained by sargs) should be a separate jira case.
> Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
> -
>
> Key: CALCITE-4189
> URL: https://issues.apache.org/jira/browse/CALCITE-4189
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Priority: Minor
>
> Statements of the form 'P OR P IS NOT TRUE' to 'TRUE' should always be true
> (please correct me if I am wrong):
> {code:java}
> > select x, X='A' as EQ,
> X='A' IS NOT TRUE as EQ_NOT_TRUE,
> (X='A') OR ((X='A') IS NOT TRUE) as EQ_OR_EQ_NOT_TRUE
> from (values 'A', 'B', null) as t(x);
> +---+---+-+---+
> | X | EQ | EQ_NOT_TRUE | EQ_OR_EQ_NOT_TRUE |
> +---+---+-+---+
> | A | true | false | true |
> | B | false | true| true |
> | | | true| true |
> +---+---+-+---+
> {code}
> Here a test case for the expected behavior:
> {code:java}
> @Test void testSimplifyPOrPNotTrue() {
> checkSimplify(
> and(
> vBool(),
> or(
> eq(vInt(), literal(1)),
> isNotTrue(eq(vInt(), literal(1)))
> )),
> "?0.bool0");
> }{code}
> There are some other, similar expressions, such as 'P IS NOT FALSE OR NOT P',
> which can be reduced to true. Maybe there's a way to handle all of them?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5967) UnsupportedOperationException while implementing a call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760074#comment-17760074
]
Julian Hyde commented on CALCITE-5967:
--
Sorry I broke this. A better fix - the right fix - would be for the calling
code to stop assuming that the list is mutable.
That I didn't find the breakage speaks to a hole in our test suite. Is there a
SQL-level test that would have found this? Your unit test is rather contrived
and frankly I don't understand it.
> UnsupportedOperationException while implementing a call that requires a
> special collator
>
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); whereas the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
> ...
> optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
> final Expression callValue =
> implementSafe(translator, call, optimizedArgValueList);
> ...
> }
> @Override Expression implementSafe(...) {
> ...
> final Expression fieldComparator =
> generateCollatorExpression(relDataType0.getCollation());
> if (fieldComparator != null) {
> argValueList.add(fieldComparator); // <---
> UnsupportedOperationException!
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5967) UnsupportedOperationException while implementing a call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5967:
Labels: pull-request-available (was: )
> UnsupportedOperationException while implementing a call that requires a
> special collator
>
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); whereas the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
> ...
> optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
> final Expression callValue =
> implementSafe(translator, call, optimizedArgValueList);
> ...
> }
> @Override Expression implementSafe(...) {
> ...
> final Expression fieldComparator =
> generateCollatorExpression(relDataType0.getCollation());
> if (fieldComparator != null) {
> argValueList.add(fieldComparator); // <---
> UnsupportedOperationException!
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5967) UnsupportedOperationException while implementing a call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5967:
---
Summary: UnsupportedOperationException while implementing a call that
requires a special collator (was: UnsupportedOperationException while
implementing a call that requires a special collator )
> UnsupportedOperationException while implementing a call that requires a
> special collator
>
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); whereas the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
> ...
> optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
> final Expression callValue =
> implementSafe(translator, call, optimizedArgValueList);
> ...
> }
> @Override Expression implementSafe(...) {
> ...
> final Expression fieldComparator =
> generateCollatorExpression(relDataType0.getCollation());
> if (fieldComparator != null) {
> argValueList.add(fieldComparator); // <---
> UnsupportedOperationException!
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5967) UnsupportedOperationException while implementing a call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5967:
---
Summary: UnsupportedOperationException while implementing a call that
requires a special collator (was: UnsupportedOperationException while
implementing call that requires a special collator )
> UnsupportedOperationException while implementing a call that requires a
> special collator
> -
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); whereas the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
> ...
> optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
> final Expression callValue =
> implementSafe(translator, call, optimizedArgValueList);
> ...
> }
> @Override Expression implementSafe(...) {
> ...
> final Expression fieldComparator =
> generateCollatorExpression(relDataType0.getCollation());
> if (fieldComparator != null) {
> argValueList.add(fieldComparator); // <---
> UnsupportedOperationException!
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5967) UnsupportedOperationException while implementing call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-5967:
---
Description:
Regression introduced by a minor change within CALCITE-5914, detected while
testing a downstream project with the latest Calcite main.
CALCITE-5914 (see
[2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
introduced this apparently innocuous change in
{{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
{code}
// old
argValueList.stream()
.map(AbstractRexCallImplementor::unboxExpression)
.collect(Collectors.toList());
=>
// new
Util.transform(argValueList,
AbstractRexCallImplementor::unboxExpression);
{code}
Both expressions seem equivalent, however there is a subtle difference: the old
one returns an {{ArrayList}} (where we can add new elements); whereas the new
one returns a {{TransformingList}} that extends {{AbstractList}} and that does
not support {{List#add}}.
After calling {{unboxIfNecessary}}, we might need to modify the argument list
if we need a special collator to perform the operation:
{code}
private ParameterExpression genValueStatement(...) {
...
optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
final Expression callValue =
implementSafe(translator, call, optimizedArgValueList);
...
}
@Override Expression implementSafe(...) {
...
final Expression fieldComparator =
generateCollatorExpression(relDataType0.getCollation());
if (fieldComparator != null) {
argValueList.add(fieldComparator); // <---
UnsupportedOperationException!
}
...
{code}
was:
Regression introduced by a minor change within CALCITE-5914, detected while
testing a downstream project with the latest Calcite main.
CALCITE-5914 (see
[2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
introduced this apparently innocuous change in
{{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
{code}
// old
argValueList.stream()
.map(AbstractRexCallImplementor::unboxExpression)
.collect(Collectors.toList());
=>
// new
Util.transform(argValueList,
AbstractRexCallImplementor::unboxExpression);
{code}
Both expressions seem equivalent, however there is a subtle difference: the old
one returns an {{ArrayList}} (where we can add new elements); wheres the new
one returns a {{TransformingList}} that extends {{AbstractList}} and that does
not support {{List#add}}.
After calling {{unboxIfNecessary}}, we might need to modify the argument list
if we need a special collator to perform the operation:
{code}
private ParameterExpression genValueStatement(...) {
...
optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
final Expression callValue =
implementSafe(translator, call, optimizedArgValueList);
...
}
@Override Expression implementSafe(...) {
...
final Expression fieldComparator =
generateCollatorExpression(relDataType0.getCollation());
if (fieldComparator != null) {
argValueList.add(fieldComparator); // <---
UnsupportedOperationException!
}
...
{code}
> UnsupportedOperationException while implementing call that requires a special
> collator
> ---
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); whereas the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression
[jira] [Commented] (CALCITE-5967) UnsupportedOperationException while implementing call that requires a special collator
[
https://issues.apache.org/jira/browse/CALCITE-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760020#comment-17760020
]
Ruben Q L commented on CALCITE-5967:
Problem can be reproduced by adding this test into
{{EnumerableStringComparisonTest}}:
{code}
@Test void testFilterStringSpecialCollation() {
tester()
.withRel(builder -> builder
.values(
createRecordVarcharSpecialCollation(builder),
"Legal", "presales", "hr", "Administration", "MARKETING")
.filter(
builder.equals(
builder.field(1, 0, "name"),
builder.literal("MARKETING")))
.build())
.explainHookMatches(""
+ "EnumerableCalc(expr#0=[{inputs}], expr#1=['MARKETING'],
expr#2=[=($t0, $t1)], name=[$t0], $condition=[$t2])\n"
+ " EnumerableValues(tuples=[[{ 'Legal' }, { 'presales' }, { 'hr'
}, { 'Administration' }, { 'MARKETING' }]])\n")
.returnsUnordered("name=MARKETING");
}
{code}
which fails with:
{noformat}
...
Suppressed: java.lang.UnsupportedOperationException
at java.base/java.util.AbstractList.add(AbstractList.java:153)
at java.base/java.util.AbstractList.add(AbstractList.java:111)
at
org.apache.calcite.adapter.enumerable.RexImpTable$BinaryImplementor.implementSafe(RexImpTable.java:2876)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3768)
at
org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3730)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1184)
...
{noformat}
> UnsupportedOperationException while implementing call that requires a special
> collator
> ---
>
> Key: CALCITE-5967
> URL: https://issues.apache.org/jira/browse/CALCITE-5967
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Fix For: 1.36.0
>
>
> Regression introduced by a minor change within CALCITE-5914, detected while
> testing a downstream project with the latest Calcite main.
> CALCITE-5914 (see
> [2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
> introduced this apparently innocuous change in
> {{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
> {code}
> // old
> argValueList.stream()
> .map(AbstractRexCallImplementor::unboxExpression)
> .collect(Collectors.toList());
> =>
> // new
> Util.transform(argValueList,
> AbstractRexCallImplementor::unboxExpression);
> {code}
> Both expressions seem equivalent, however there is a subtle difference: the
> old one returns an {{ArrayList}} (where we can add new elements); wheres the
> new one returns a {{TransformingList}} that extends {{AbstractList}} and that
> does not support {{List#add}}.
> After calling {{unboxIfNecessary}}, we might need to modify the argument list
> if we need a special collator to perform the operation:
> {code}
> private ParameterExpression genValueStatement(...) {
> ...
> optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
> final Expression callValue =
> implementSafe(translator, call, optimizedArgValueList);
> ...
> }
> @Override Expression implementSafe(...) {
> ...
> final Expression fieldComparator =
> generateCollatorExpression(relDataType0.getCollation());
> if (fieldComparator != null) {
> argValueList.add(fieldComparator); // <---
> UnsupportedOperationException!
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5967) UnsupportedOperationException while implementing call that requires a special collator
Ruben Q L created CALCITE-5967:
--
Summary: UnsupportedOperationException while implementing call
that requires a special collator
Key: CALCITE-5967
URL: https://issues.apache.org/jira/browse/CALCITE-5967
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Ruben Q L
Assignee: Ruben Q L
Fix For: 1.36.0
Regression introduced by a minor change within CALCITE-5914, detected while
testing a downstream project with the latest Calcite main.
CALCITE-5914 (see
[2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6])
introduced this apparently innocuous change in
{{RexImpTable#AbstractRexCallImplementor#unboxIfNecessary}}:
{code}
// old
argValueList.stream()
.map(AbstractRexCallImplementor::unboxExpression)
.collect(Collectors.toList());
=>
// new
Util.transform(argValueList,
AbstractRexCallImplementor::unboxExpression);
{code}
Both expressions seem equivalent, however there is a subtle difference: the old
one returns an {{ArrayList}} (where we can add new elements); wheres the new
one returns a {{TransformingList}} that extends {{AbstractList}} and that does
not support {{List#add}}.
After calling {{unboxIfNecessary}}, we might need to modify the argument list
if we need a special collator to perform the operation:
{code}
private ParameterExpression genValueStatement(...) {
...
optimizedArgValueList = unboxIfNecessary(optimizedArgValueList);
final Expression callValue =
implementSafe(translator, call, optimizedArgValueList);
...
}
@Override Expression implementSafe(...) {
...
final Expression fieldComparator =
generateCollatorExpression(relDataType0.getCollation());
if (fieldComparator != null) {
argValueList.add(fieldComparator); // <---
UnsupportedOperationException!
}
...
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5965) Avoid unnecessary String concatenations in the RexFieldAccess constructor to improve the performance
[ https://issues.apache.org/jira/browse/CALCITE-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759994#comment-17759994 ] Julian Hyde commented on CALCITE-5965: -- I saw you converted the call to Preconditions.checkArgument into an “if”. Could you instead pass a template and arguments to checkArgument? It is as efficient as your code and more readable. Also statically import checkArgument. > Avoid unnecessary String concatenations in the RexFieldAccess constructor to > improve the performance > > > Key: CALCITE-5965 > URL: https://issues.apache.org/jira/browse/CALCITE-5965 > Project: Calcite > Issue Type: Task >Reporter: Thomas Rebele >Assignee: Thomas Rebele >Priority: Trivial > Labels: pull-request-available > Fix For: 1.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5966) Upgrade commons-dbcp2 to 2.9.0
[ https://issues.apache.org/jira/browse/CALCITE-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5966: Labels: pull-request-available (was: ) > Upgrade commons-dbcp2 to 2.9.0 > -- > > Key: CALCITE-5966 > URL: https://issues.apache.org/jira/browse/CALCITE-5966 > Project: Calcite > Issue Type: Task >Reporter: ZhangJian He >Assignee: ZhangJian He >Priority: Minor > Labels: pull-request-available > > Upgrade commons-dbcp2 from 2.6.0 to 2.9.0. 2.6.0 version was released in > 2019. Regular update. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5966) Upgrade commons-dbcp2 to 2.9.0
[ https://issues.apache.org/jira/browse/CALCITE-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhangJian He updated CALCITE-5966: -- Description: Upgrade commons-dbcp2 from 2.6.0 to 2.9.0. 2.6.0 version was released in 2019. Regular update. > Upgrade commons-dbcp2 to 2.9.0 > -- > > Key: CALCITE-5966 > URL: https://issues.apache.org/jira/browse/CALCITE-5966 > Project: Calcite > Issue Type: Task >Reporter: ZhangJian He >Assignee: ZhangJian He >Priority: Minor > > Upgrade commons-dbcp2 from 2.6.0 to 2.9.0. 2.6.0 version was released in > 2019. Regular update. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5966) Upgrade commons-dbcp2 to 2.9.0
ZhangJian He created CALCITE-5966: - Summary: Upgrade commons-dbcp2 to 2.9.0 Key: CALCITE-5966 URL: https://issues.apache.org/jira/browse/CALCITE-5966 Project: Calcite Issue Type: Task Reporter: ZhangJian He Assignee: ZhangJian He -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759985#comment-17759985 ] Runkang He commented on CALCITE-5957: - [~zstan] I will review it these days. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5962) Allow Spark-style syntax "LEFT ANTI JOIN" in Babel parser
[ https://issues.apache.org/jira/browse/CALCITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759982#comment-17759982 ] LakeShen commented on CALCITE-5962: --- Thank you for opening this PR, I left a couple of comments! > Allow Spark-style syntax "LEFT ANTI JOIN" in Babel parser > - > > Key: CALCITE-5962 > URL: https://issues.apache.org/jira/browse/CALCITE-5962 > Project: Calcite > Issue Type: Wish >Reporter: LiYuE >Assignee: Mingcan Wang >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-28-19-47-40-712.png > > > Currently, Spark SQL supports parsing the "anti join" SQL syntax [Spark anti > join|https://spark.apache.org/docs/3.4.1/sql-ref-syntax-qry-select-join.html#anti-join], > but the > org.apache.calcite.sql.JoinType.java in Calcite does not include this > enumeration. Therefore, it is hoped that Calcite can add an enumeration type > for anti join to be compatible with the Spark syntax. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5965) Avoid unnecessary String concatenations in the RexFieldAccess constructor to improve the performance
[ https://issues.apache.org/jira/browse/CALCITE-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5965: Labels: pull-request-available (was: ) > Avoid unnecessary String concatenations in the RexFieldAccess constructor to > improve the performance > > > Key: CALCITE-5965 > URL: https://issues.apache.org/jira/browse/CALCITE-5965 > Project: Calcite > Issue Type: Task >Reporter: Thomas Rebele >Assignee: Thomas Rebele >Priority: Trivial > Labels: pull-request-available > Fix For: 1.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-4189) Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
[
https://issues.apache.org/jira/browse/CALCITE-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759958#comment-17759958
]
hongyu guo commented on CALCITE-4189:
-
Do you still want to use Sargs to implement this simplifications? (As you
mentioned in your previous comment, it may have been 3 years already)
My understanding of Sargs is not sufficient, so if Using it, I will do more
code reading before starting work.
> Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
> -
>
> Key: CALCITE-4189
> URL: https://issues.apache.org/jira/browse/CALCITE-4189
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Priority: Minor
>
> Statements of the form 'P OR P IS NOT TRUE' to 'TRUE' should always be true
> (please correct me if I am wrong):
> {code:java}
> > select x, X='A' as EQ,
> X='A' IS NOT TRUE as EQ_NOT_TRUE,
> (X='A') OR ((X='A') IS NOT TRUE) as EQ_OR_EQ_NOT_TRUE
> from (values 'A', 'B', null) as t(x);
> +---+---+-+---+
> | X | EQ | EQ_NOT_TRUE | EQ_OR_EQ_NOT_TRUE |
> +---+---+-+---+
> | A | true | false | true |
> | B | false | true| true |
> | | | true| true |
> +---+---+-+---+
> {code}
> Here a test case for the expected behavior:
> {code:java}
> @Test void testSimplifyPOrPNotTrue() {
> checkSimplify(
> and(
> vBool(),
> or(
> eq(vInt(), literal(1)),
> isNotTrue(eq(vInt(), literal(1)))
> )),
> "?0.bool0");
> }{code}
> There are some other, similar expressions, such as 'P IS NOT FALSE OR NOT P',
> which can be reduced to true. Maybe there's a way to handle all of them?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-4189) Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
[
https://issues.apache.org/jira/browse/CALCITE-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759958#comment-17759958
]
hongyu guo edited comment on CALCITE-4189 at 8/29/23 1:11 PM:
--
Hi [~julianhyde], do you still want to use Sargs to implement this
simplifications? (As you mentioned in your previous comment, it may have been 3
years already)
My understanding of Sargs is not sufficient, so if using it, I will do more
code reading before starting work.
was (Author: JIRAUSER300840):
Do you still want to use Sargs to implement this simplifications? (As you
mentioned in your previous comment, it may have been 3 years already)
My understanding of Sargs is not sufficient, so if Using it, I will do more
code reading before starting work.
> Simplify 'p OR (p IS NOT TRUE)' to 'TRUE'
> -
>
> Key: CALCITE-4189
> URL: https://issues.apache.org/jira/browse/CALCITE-4189
> Project: Calcite
> Issue Type: Improvement
>Reporter: Thomas Rebele
>Priority: Minor
>
> Statements of the form 'P OR P IS NOT TRUE' to 'TRUE' should always be true
> (please correct me if I am wrong):
> {code:java}
> > select x, X='A' as EQ,
> X='A' IS NOT TRUE as EQ_NOT_TRUE,
> (X='A') OR ((X='A') IS NOT TRUE) as EQ_OR_EQ_NOT_TRUE
> from (values 'A', 'B', null) as t(x);
> +---+---+-+---+
> | X | EQ | EQ_NOT_TRUE | EQ_OR_EQ_NOT_TRUE |
> +---+---+-+---+
> | A | true | false | true |
> | B | false | true| true |
> | | | true| true |
> +---+---+-+---+
> {code}
> Here a test case for the expected behavior:
> {code:java}
> @Test void testSimplifyPOrPNotTrue() {
> checkSimplify(
> and(
> vBool(),
> or(
> eq(vInt(), literal(1)),
> isNotTrue(eq(vInt(), literal(1)))
> )),
> "?0.bool0");
> }{code}
> There are some other, similar expressions, such as 'P IS NOT FALSE OR NOT P',
> which can be reduced to true. Maybe there's a way to handle all of them?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5964) Support additional metadata attributes in GET_TABLES and GET_COLUMNS
[
https://issues.apache.org/jira/browse/CALCITE-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759956#comment-17759956
]
Oliver Lee commented on CALCITE-5964:
-
Thanks for taking a look [~julianhyde]
I had just gotten to reading into {{CursorFactory}} before you've replied. It
looks like the proper style to use for no set class and values not being
directly read from the object's attributes is {{ARRAY}} based off of what I'm
seeing at {{{}deduce(){}}}.
My understanding so far of how CursorFactory styles works is that {{Style.MAP}}
is for the case when the enumerable is just a map object (not applicable here),
and {{Style.ARRAY}} is for scenarios when we're not reading right off of a
class's attributes.
It doesn't seem like there exists a composite style allowing for arrays + map.
I'm looking at the example of Struct usage in
{{AvaticaResultSetConversionsTest.java}} for understanding.
To me that sounds like it would be best if the server supplies the Iterable
object with the map keys already flattened into attributes.
That ties into the 3rd point you brought up in that they don't necessarily have
to come from a list of {{MetaTable}} instances if I'm understanding you
correctly.
I assumed that was a restriction because the current implementation in
{{CalciteMetaImpl}} calls {{tables()}} which returns {{Iterable}}
> Support additional metadata attributes in GET_TABLES and GET_COLUMNS
>
>
> Key: CALCITE-5964
> URL: https://issues.apache.org/jira/browse/CALCITE-5964
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
>
> The goal is to add to Avatica a mechanism such that additional metadata
> fields pertaining to tables and columns can be transmitted alongside the
> standard JDBC
> [getTables|https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)]
> and {{getColumns}} calls.
> The Avatica client needs the response to be extensible such that revisions to
> metadata fields send and future additions does not require a new JAR file.
> Requirements:
> # Avatica user does not need to download new jar files if the server decides
> to send over new metadata data in the future
> # If the client makes modifications to support additional columns, they
> should always be present in the call and appear with null values, as opposed
> to complete omission (Number of columns in response stays the same)
> # Can handle attributes of varying types i.e. {{numberOne: int}} and
> {{booleanOne: boolean}}
> # Allows value retrieval from the {{ResultSet}} through calling
> {{resultSet.getInt(“booleanOne”)}} or {{resultSet.getBoolean(“booleanOne”)}}
> Current proposal is to modify the {{MetaTable}} and {{MetaColumn}} classes to
> include a map.
> {{{}HashMap{}}}, such that when instantiating the
> {{CalciteMetaTable}} in the {{{}ResultSet{}}}, new entries could be added in
> the future without changes to Avatica.
> One we have a list of additional metadata fields to be emitted in
> {{{}CalciteMetaImpl{}}}, the {{ResultSet}} would be created with the
> appropriate values.
>
> There are still some challenges identified below and I would love some input:
> Challenges:
> * Currently the {{MetaTable}} class that is instantiated is a
> {{{}CalciteMetaImpl{}}}. For the {{getTables()}} call, the response will be a
> list composed of schema tables of class {{CalciteMetaTable}} and database
> tables which can potentially be overloaded into 1 or more different
> subclasses. From this one heterogeneous list, we must determine the full list
> of columns to be included in the additional metadata hash. My initial plan
> was to provide a function in Calcite’s {{Table}} class such as
> {{getAdditionalColumns}} and allow it to be overloaded, but then I discovered
> the heterogeneity of the list.
> * Modifying the MetaTable class to include the hashmap of values could be
> easily done, but the challenge lies at {{{}RemoteMeta{}}}, to be able to
> serialize this cleanly so that requirement (4) is met and users can retrieve
> the values nicely. {{RemoteMeta}} currently serializes the response using
> reflection by looking at MetaTable.class and its attributes. The addition of
> one map is not immediately compatible with iterating over the keys of the map
> and turning each of those into fields. I’m looking into the idea of
> processing the enumerable in {{CalciteMetaImpl}} before the Frame gets created
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5956) Support parsing non-standard collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759955#comment-17759955
]
hongyu guo commented on CALCITE-5956:
-
[~julianhyde], I think use "<>" or "()" is not a big problem, dialect can help
us convert to appropriate syntax when user connect to different DBMS.
I +1 for "MAP".
Another question: Should we add {{ARRAY}} and {{MULTISET}} to core Parser?
* Add to core: build a stronger parser, and better support {{MAP}} in
the future (my opinion)
* Add to babel: core parser is too heavy. ([~jiajunbernoulli]'s opinion)
I want to do some work for parsing {{ARRAY}} and {{MULTISET}} first after
we make a decision:)
> Support parsing non-standard collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5965) Avoid unnecessary String concatenations in the RexFieldAccess constructor to improve the performance
Thomas Rebele created CALCITE-5965: -- Summary: Avoid unnecessary String concatenations in the RexFieldAccess constructor to improve the performance Key: CALCITE-5965 URL: https://issues.apache.org/jira/browse/CALCITE-5965 Project: Calcite Issue Type: Task Reporter: Thomas Rebele Assignee: Thomas Rebele Fix For: 1.36.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Description:
current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
interval to number. but it throws NPE when family is null.
It will cause some types such as row type (family is null) raise a NPE.
e.g. If we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{noformat}
java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
row(a integer, b tinyint)))": Unable to implement
EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
$t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B) NOT
NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0 cpu,
0.0 io}, id = 20
EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost = \{1.0
rows, 1.0 cpu, 0.0 io}, id = 13
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at
org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Updated] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Description:
current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
interval to number. but it throws NPE when family is null.
It will cause some types such as row type (family is null) raise a NPE.
e.g. If we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{noformat}
java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
row(a integer, b tinyint)))": Unable to implement
EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
$t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B) NOT
NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0 cpu,
0.0 io}, id = 20
EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost = \{1.0
rows, 1.0 cpu, 0.0 io}, id = 13
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at
org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Commented] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759866#comment-17759866 ] Evgeny Stanilovsky commented on CALCITE-5957: - [~Runking], [~shenlang] i don`t dig deeper here, just fix for DATE '1945-2-2' case, plz take a look and possibly approve PR, thanks. > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5957: Labels: pull-request-available (was: ) > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: pull-request-available > Attachments: image-2023-08-27-19-09-33-284.png > > Time Spent: 10m > Remaining Estimate: 0h > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Description:
current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
interval to number. but it throws NPE when family is null.
It will cause some types such as row type (family is null) raise a NPE.
e.g. If we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{noformat}
java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
row(a integer, b tinyint)))": Unable to implement
EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
$t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B) NOT
NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0 cpu,
0.0 io}, id = 20
EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost = \{1.0
rows, 1.0 cpu, 0.0 io}, id = 13
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at
org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Updated] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Description:
current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
interval to number. but it throws NPE when family is null.
It will cause some types such as row type (family is null) raise a NPE.
e.g. If we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{noformat}
java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
row(a integer, b tinyint)))": Unable to implement
EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
$t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B) NOT
NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0 cpu,
0.0 io}, id = 20
EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost = \{1.0
rows, 1.0 cpu, 0.0 io}, id = 13
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at
org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Updated] (CALCITE-5960) CAST failed if SqlTypeFamily of targetType is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Description:
current RexToLixTranslator#translateCast#scaleIntervalToNumber will scale
interval to number. but it throws NPE when family is null.
It will cause some types such as row type (family is null) raise a NPE.
e.g. If we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{noformat}
java.sql.SQLException: Error while executing SQL "values (CAST(row(1, 2) as
row(a integer, b tinyint)))": Unable to implement
EnumerableCalc(expr#0=[\{inputs}], expr#1=[1], expr#2=[2], expr#3=[ROW($t1,
$t2)], expr#4=[CAST($t3):RecordType(INTEGER NOT NULL A, TINYINT NOT NULL B) NOT
NULL], EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = \{2.0 rows, 7.0 cpu,
0.0 io}, id = 20
EnumerableValues(tuples=[[\{ 0 }]]): rowcount = 1.0, cumulative cost = \{1.0
rows, 1.0 cpu, 0.0 io}, id = 13
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:12684)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:224)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:223)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:238)
at
org.apache.calcite.test.SqlOperatorTest.testCastRow(SqlOperatorTest.java:6103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Assigned] (CALCITE-5957) Valid DATE '1945-2-2' is not accepted due to regression
[ https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned CALCITE-5957: --- Assignee: Evgeny Stanilovsky > Valid DATE '1945-2-2' is not accepted due to regression > --- > > Key: CALCITE-5957 > URL: https://issues.apache.org/jira/browse/CALCITE-5957 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Evgeny Stanilovsky >Priority: Major > Attachments: image-2023-08-27-19-09-33-284.png > > > DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result > check of `testCastStringToDateTime`, we find that Calcite accepted DATE > '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression > that we need to fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CALCITE-5963) Simplify 'x OR NOT(x)' to TRUE
[ https://issues.apache.org/jira/browse/CALCITE-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongyu guo closed CALCITE-5963. --- Resolution: Duplicate > Simplify 'x OR NOT(x)' to TRUE > -- > > Key: CALCITE-5963 > URL: https://issues.apache.org/jira/browse/CALCITE-5963 > Project: Calcite > Issue Type: New Feature >Reporter: hongyu guo >Assignee: hongyu guo >Priority: Major > > When unknownAs is TRUE, or type of x is not nullable, Calcite can simpify: > x OR NOT( x ) ==> TRUE -- This message was sent by Atlassian Jira (v8.20.10#820010)
