[jira] [Updated] (CALCITE-5960) Inapplicable type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
https://issues.apache.org/jira/browse/CALCITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5960:
-
Summary: Inapplicable type should pass through the
RexToLixTranslator#scaleIntervalToNumber instead of NPE (was: Unexpected type
should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE)
> Inapplicable type should pass through the
> RexToLixTranslator#scaleIntervalToNumber instead of NPE
> -
>
> Key: CALCITE-5960
> URL: https://issues.apache.org/jira/browse/CALCITE-5960
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> current RexToLixTranslator#scaleIntervalToNumber will scale interval to
> number. but it throw NPE when family is null. It will cause some types such
> as row type (family is null) raise a NPE. In fact this function should do its
> logic for expected type, otherwise just return the original operand is ok.
> {code:java}
> private static Expression scaleIntervalToNumber(
> RelDataType sourceType,
> RelDataType targetType,
> Expression operand) {
> switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
> () -> "SqlTypeFamily for " + targetType)) {
> case NUMERIC:
> switch (sourceType.getSqlTypeName()) {
> case INTERVAL_YEAR:
> // omit some code
> default:
> break;
> }
> break;
> default:
> break;
> }
> return operand;
> } {code}
> e.g. we call
> {code:java}
> CAST(row(1, 2) as row(a integer, b tinyint)){code}
> it will cause NPE:
> {code:java}
> Suppressed: java.lang.NullPointerException: SqlTypeFamily for
> RecordType(INTEGER A, TINYINT B) at
> java.base/java.util.Objects.requireNonNull(Objects.java:347) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
> 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)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
> at
> org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> ... 89 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omit some code
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
e.g. we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omit some codes
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
e.g. we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.vis
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omit some codes
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
e.g. we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
e.g. we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
e.g. we call
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
it will cause NPE:
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(),
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(), --> error
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
private static Expression scaleIntervalToNumber(
RelDataType sourceType,
RelDataType targetType,
Expression operand) {
switch (requireNonNull(targetType.getSqlTypeName().getFamily(),
() -> "SqlTypeFamily for " + targetType)) {
case NUMERIC:
switch (sourceType.getSqlTypeName()) {
case INTERVAL_YEAR:
// omitm
default:
break;
}
break;
default:
break;
}
return operand;
} {code}
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.a
[jira] [Created] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
Ran Tao created CALCITE-5960:
Summary: Unexpected type should pass through the
RexToLixTranslator#scaleIntervalToNumber instead of NPE
Key: CALCITE-5960
URL: https://issues.apache.org/jira/browse/CALCITE-5960
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.35.0
Reporter: Ran Tao
Assignee: Ran Tao
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just pass the original operand is ok.
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5960) Unexpected type should pass through the RexToLixTranslator#scaleIntervalToNumber instead of NPE
[
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#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just return the original operand is ok.
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
... 89 more
{code}
was:
current RexToLixTranslator#scaleIntervalToNumber will scale interval to number.
but it throw NPE when family is null. It will cause some types such as row type
(family is null) raise a NPE. In fact this function should do its logic for
expected type, otherwise just pass the original operand is ok.
{code:java}
CAST(row(1, 2) as row(a integer, b tinyint)){code}
{code:java}
Suppressed: java.lang.NullPointerException: SqlTypeFamily for
RecordType(INTEGER A, TINYINT B) at
java.base/java.util.Objects.requireNonNull(Objects.java:347) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.scaleIntervalToNumber(RexToLixTranslator.java:976)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCast(RexToLixTranslator.java:293)
at
org.apache.calcite.adapter.enumerable.RexImpTable$CastImplementor.implementSafe(RexImpTable.java:3200)
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)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1060)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:101)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:253)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:247)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:899)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:201)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:192)
at
org.apache.calcite.adapter.enumerable.En
[jira] [Commented] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[
https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759320#comment-17759320
]
Ran Tao commented on CALCITE-5958:
--
[~shenlang] hi Shen, FYI. value is sql reserved keywords from sql-92. We can
not make it to nonReservedKeywords directly. how about make it only in PG
library?
> Make the value be nonReservedKeywords(consistent with Postgres)
> ---
>
> Key: CALCITE-5958
> URL: https://issues.apache.org/jira/browse/CALCITE-5958
> Project: Calcite
> Issue Type: Improvement
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-08-27-12-33-24-000.png,
> image-2023-08-27-12-34-53-322.png
>
>
> Now in the Postgres, value could be field alias,for example:
> {code:java}
> select 1 + 1 as value {code}
> The above SQL was successfully executed in PG:
> !image-2023-08-27-12-33-24-000.png|width=275,height=210!
> In Calcite, the above SQL throws a parse error:
> !image-2023-08-27-12-34-53-322.png|width=554,height=197!
> I don't confirm whether this is a problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
[
https://issues.apache.org/jira/browse/CALCITE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5959:
--
Description:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The above results are true in Mysql and Postgres.
!image-2023-08-27-12-56-11-390.png|width=503,height=213!
But in calcite,the result is false:
{code:java}
LogicalValues(tuples=[[{ false }]]) {code}
was:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The result The Postgres and Mysql
> Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
> ---
>
> Key: CALCITE-5959
> URL: https://issues.apache.org/jira/browse/CALCITE-5959
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-08-27-12-56-11-390.png
>
>
> For the sql :
> {code:java}
> select cast(200 as boolean) {code}
> The above results are true in Mysql and Postgres.
> !image-2023-08-27-12-56-11-390.png|width=503,height=213!
> But in calcite,the result is false:
> {code:java}
> LogicalValues(tuples=[[{ false }]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
[
https://issues.apache.org/jira/browse/CALCITE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5959:
--
Attachment: image-2023-08-27-12-56-11-390.png
> Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
> ---
>
> Key: CALCITE-5959
> URL: https://issues.apache.org/jira/browse/CALCITE-5959
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-08-27-12-56-11-390.png
>
>
> For the sql :
> {code:java}
> select cast(200 as boolean) {code}
> The result The Postgres and Mysql
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
[
https://issues.apache.org/jira/browse/CALCITE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5959:
--
Description:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The result The Postgres and Mysql
was:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The Postgres and
> Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
> ---
>
> Key: CALCITE-5959
> URL: https://issues.apache.org/jira/browse/CALCITE-5959
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
>
> For the sql :
> {code:java}
> select cast(200 as boolean) {code}
> The result The Postgres and Mysql
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
[
https://issues.apache.org/jira/browse/CALCITE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5959:
--
Description:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The Postgres and
was:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The
> Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
> ---
>
> Key: CALCITE-5959
> URL: https://issues.apache.org/jira/browse/CALCITE-5959
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
>
> For the sql :
> {code:java}
> select cast(200 as boolean) {code}
> The Postgres and
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
[
https://issues.apache.org/jira/browse/CALCITE-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5959:
--
Description:
For the sql :
{code:java}
select cast(200 as boolean) {code}
The
> Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
> ---
>
> Key: CALCITE-5959
> URL: https://issues.apache.org/jira/browse/CALCITE-5959
> Project: Calcite
> Issue Type: Bug
>Reporter: LakeShen
>Priority: Major
>
> For the sql :
> {code:java}
> select cast(200 as boolean) {code}
> The
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5959) Cast(200 as boolean) should return true(consistent with Postgres and Mysql)
LakeShen created CALCITE-5959: - Summary: Cast(200 as boolean) should return true(consistent with Postgres and Mysql) Key: CALCITE-5959 URL: https://issues.apache.org/jira/browse/CALCITE-5959 Project: Calcite Issue Type: Bug Reporter: LakeShen -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[
https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5958:
--
Description:
Now in the Postgres, value could be field alias,for example:
{code:java}
select 1 + 1 as value {code}
The above SQL was successfully executed in PG:
!image-2023-08-27-12-33-24-000.png|width=275,height=210!
In Calcite, the above SQL throws a parse error:
!image-2023-08-27-12-34-53-322.png|width=554,height=197!
I don't confirm whether this is a problem
was:
Now in the Postgres, value could be field alias,for example:
{code:java}
select 1 + 1 as value {code}
The above SQL was successfully executed in PG:
!image-2023-08-27-12-33-24-000.png|width=275,height=210!
In Calcite, the above SQL throws a parse error:
!image-2023-08-27-12-34-53-322.png|width=554,height=197!
> Make the value be nonReservedKeywords(consistent with Postgres)
> ---
>
> Key: CALCITE-5958
> URL: https://issues.apache.org/jira/browse/CALCITE-5958
> Project: Calcite
> Issue Type: Improvement
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-08-27-12-33-24-000.png,
> image-2023-08-27-12-34-53-322.png
>
>
> Now in the Postgres, value could be field alias,for example:
> {code:java}
> select 1 + 1 as value {code}
> The above SQL was successfully executed in PG:
> !image-2023-08-27-12-33-24-000.png|width=275,height=210!
> In Calcite, the above SQL throws a parse error:
> !image-2023-08-27-12-34-53-322.png|width=554,height=197!
> I don't confirm whether this is a problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[
https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen updated CALCITE-5958:
--
Description:
Now in the Postgres, value could be field alias,for example:
{code:java}
select 1 + 1 as value {code}
The above SQL was successfully executed in PG:
!image-2023-08-27-12-33-24-000.png|width=275,height=210!
In Calcite, the above SQL throws a parse error:
!image-2023-08-27-12-34-53-322.png|width=554,height=197!
was:Now in the
> Make the value be nonReservedKeywords(consistent with Postgres)
> ---
>
> Key: CALCITE-5958
> URL: https://issues.apache.org/jira/browse/CALCITE-5958
> Project: Calcite
> Issue Type: Improvement
>Reporter: LakeShen
>Priority: Major
> Attachments: image-2023-08-27-12-33-24-000.png,
> image-2023-08-27-12-34-53-322.png
>
>
> Now in the Postgres, value could be field alias,for example:
> {code:java}
> select 1 + 1 as value {code}
> The above SQL was successfully executed in PG:
> !image-2023-08-27-12-33-24-000.png|width=275,height=210!
> In Calcite, the above SQL throws a parse error:
> !image-2023-08-27-12-34-53-322.png|width=554,height=197!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[ https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] LakeShen updated CALCITE-5958: -- Attachment: image-2023-08-27-12-34-53-322.png > Make the value be nonReservedKeywords(consistent with Postgres) > --- > > Key: CALCITE-5958 > URL: https://issues.apache.org/jira/browse/CALCITE-5958 > Project: Calcite > Issue Type: Improvement >Reporter: LakeShen >Priority: Major > Attachments: image-2023-08-27-12-33-24-000.png, > image-2023-08-27-12-34-53-322.png > > > Now in the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[ https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] LakeShen updated CALCITE-5958: -- Attachment: image-2023-08-27-12-33-24-000.png > Make the value be nonReservedKeywords(consistent with Postgres) > --- > > Key: CALCITE-5958 > URL: https://issues.apache.org/jira/browse/CALCITE-5958 > Project: Calcite > Issue Type: Improvement >Reporter: LakeShen >Priority: Major > Attachments: image-2023-08-27-12-33-24-000.png > > > Now in the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
[ https://issues.apache.org/jira/browse/CALCITE-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] LakeShen updated CALCITE-5958: -- Description: Now in the > Make the value be nonReservedKeywords(consistent with Postgres) > --- > > Key: CALCITE-5958 > URL: https://issues.apache.org/jira/browse/CALCITE-5958 > Project: Calcite > Issue Type: Improvement >Reporter: LakeShen >Priority: Major > > Now in the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5958) Make the value be nonReservedKeywords(consistent with Postgres)
LakeShen created CALCITE-5958: - Summary: Make the value be nonReservedKeywords(consistent with Postgres) Key: CALCITE-5958 URL: https://issues.apache.org/jira/browse/CALCITE-5958 Project: Calcite Issue Type: Improvement Reporter: LakeShen -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (CALCITE-4850) Wrong result retrieving from ARRAY with mixed INTEGER and DECIMAL elements
[ https://issues.apache.org/jira/browse/CALCITE-4850 ]
Ran Tao deleted comment on CALCITE-4850:
--
was (Author: lemonjing):
calcite-5948 is parent issue of this.
> Wrong result retrieving from ARRAY with mixed INTEGER and DECIMAL elements
> --
>
> Key: CALCITE-4850
> URL: https://issues.apache.org/jira/browse/CALCITE-4850
> Project: Calcite
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The issue is a follow-up for
> https://issues.apache.org/jira/browse/CALCITE-4602?focusedCommentId=17427917&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17427917
> to reproduce
> {code:sql}
> select array[1.1, 1];
> +-+
> | EXPR$0|
> +-+
> | [1.1, 0E+1] |
> +-+
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[ https://issues.apache.org/jira/browse/CALCITE-5948 ]
Ran Tao deleted comment on CALCITE-5948:
--
was (Author: lemonjing):
calcite-4850 is a child issue of this.
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
>
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not;
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must
> be of the same type]
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
> {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
> public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
> --> we need explicit cast here
> return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759307#comment-17759307
]
Ran Tao commented on CALCITE-5948:
--
calcite-4850 is a child issue of this.
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
>
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not;
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must
> be of the same type]
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
> {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
> public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
> --> we need explicit cast here
> return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-4850) Wrong result retrieving from ARRAY with mixed INTEGER and DECIMAL elements
[
https://issues.apache.org/jira/browse/CALCITE-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759306#comment-17759306
]
Ran Tao commented on CALCITE-4850:
--
calcite-5948 is parent issue of this.
> Wrong result retrieving from ARRAY with mixed INTEGER and DECIMAL elements
> --
>
> Key: CALCITE-4850
> URL: https://issues.apache.org/jira/browse/CALCITE-4850
> Project: Calcite
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The issue is a follow-up for
> https://issues.apache.org/jira/browse/CALCITE-4602?focusedCommentId=17427917&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17427917
> to reproduce
> {code:sql}
> select array[1.1, 1];
> +-+
> | EXPR$0|
> +-+
> | [1.1, 0E+1] |
> +-+
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-5940) Add the Rules to optimize Limit
[
https://issues.apache.org/jira/browse/CALCITE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
LakeShen reassigned CALCITE-5940:
-
Assignee: LakeShen
> Add the Rules to optimize Limit
> ---
>
> Key: CALCITE-5940
> URL: https://issues.apache.org/jira/browse/CALCITE-5940
> Project: Calcite
> Issue Type: New Feature
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
>
> Now in calcite,the Limit will be represented using
> LogicalSort(fetch=[xx]),but there are few rules to optimize Limit.
> In trino and presto,there are many optimization rules to optimize Limit.
> For example,the sql:
> {code:java}
> select * from nation limit 0 {code}
> The limit 0 will use empty ValuesNode(Calcite LogicalValues) to optimize,so
> the SQL is not delivered to the Worker compute,the rule could see:
> [EvaluateZeroLimit|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/EvaluateZeroLimit.java#L28C1-L28C31]
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (select * from nation limit 1) limit
> 10 {code}
> It would be optimized by
> [MergeLimits|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimits.java#L26]
> rule to:
> {code:java}
> select concat('-',N_REGIONKEY) from nation limit 10 {code}
> The value of limit takes the minimum of the outer limit and the inner limit.
> The sql:
> {code:java}
> select concat('-',N_REGIONKEY) from (SELECT * FROM nation order BY
> N_REGIONKEY DESC LIMIT 1) limit 10 {code}
> It would be optimized by
> [MergeLimitWithTopN|https://github.com/prestodb/presto/blob/fea80c96ddfe4dc42f79c3cff9294b88595275ce/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/MergeLimitWithTopN.java#L28C1-L28C31]
> rule to:
> {code:java}
> SELECT concat('-',N_REGIONKEY) FROM nation order BY N_REGIONKEY DESC LIMIT
> 10{code}
> So I propose to add these three rules to Calcite as well, to optimize the
> Limit case.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5914) Cache compiled regular expressions in SQL function runtime
[
https://issues.apache.org/jira/browse/CALCITE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759275#comment-17759275
]
Julian Hyde commented on CALCITE-5914:
--
[~thomas.rebele], My change does not go as far as your proposal. A function
object could potentially optimize if it knows that a particular argument is a
literal (and will therefore always have the same value) but the present
solution does not support that. I wanted to keep things simple at first. If you
want to go further (while still keeping the simple cases simple) please log a
follow-on Jira case.
> Cache compiled regular expressions in SQL function runtime
> --
>
> Key: CALCITE-5914
> URL: https://issues.apache.org/jira/browse/CALCITE-5914
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Cache compiled regular expressions (and other amortized work) in SQL function
> runtime. Compiling a regular expression to a pattern is expensive (compared
> to the cost of matching, given an existing pattern) and therefore caching the
> compiled form will yield performance benefits if the regular expression is
> constant or has a small number of values.
> Consider the following query:
> {code:java}
> SELECT ename, job, RLIKE(ename, 'A.*'), RLIKE(ename, job || '.*')
> FROM emp
> {code}
> The first regular expression, '{{A.\*}}', is constant and can be compiled at
> prepare time or at the start of execution; the second regular expression,
> {{job || '.\*'}}, might vary from one row to the next. However if the {{job}}
> column has a small number of values it still might be beneficial to cache the
> compiled regular expression.
> If {{SqlFunctions.rlike}} could use a cache (mapping from {{String}} to
> {{{}java.util.regex.Pattern{}}}) then it would achieve benefits in both the
> constant and non-constant cases.
> The cache needs to:
> * be thread-safe (in case queries are executing using multiple threads),
> * return thread-safe objects (as is {{{}Pattern{}}}),
> * have bounded space (so that a query doesn't blow memory with 1 million
> distinct regular expressions),
> * disposed after the query has terminated,
> * (ideally) share with regexes of the same language in the same query,
> * not conflict with regexes of different languages in the same query.
> One possible implementation is to add an {{interface FunctionState}}, with
> subclasses including {{class RegexpCache}}, and if argument 1 of a function
> is a subclass of {{FunctionState}} the compiler would initialize the state in
> the generated code. The function can rely on the state argument being
> initialized, and being the same object from one call to the next. Example:
> {code:java}
> interface FunctionState {
> }
> class RegexpCache implements FunctionState {
> final Cache cache = ...;
> }
> {code}
> This change should install the cache for all applicable functions, including
> LIKE, ILIKE, RLIKE, SIMILAR, posix regex, REGEXP_REPLACE (MySQL, Oracle),
> REGEXP_CONTAINS (BigQuery), other BigQuery REGEXP_ functions, PARSE_URL,
> JSON_REPLACE, PARSE_TIMESTAMP.
> It can also be used for functions that have mutable state, e.g. {{RANDOM}}
> with and without a seed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5914) Cache compiled regular expressions in SQL function runtime
[
https://issues.apache.org/jira/browse/CALCITE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5914.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[2a96512c|https://github.com/apache/calcite/commit/2a96512c352bda4a5d9c0c80730f5c115ac363d6].
> Cache compiled regular expressions in SQL function runtime
> --
>
> Key: CALCITE-5914
> URL: https://issues.apache.org/jira/browse/CALCITE-5914
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Cache compiled regular expressions (and other amortized work) in SQL function
> runtime. Compiling a regular expression to a pattern is expensive (compared
> to the cost of matching, given an existing pattern) and therefore caching the
> compiled form will yield performance benefits if the regular expression is
> constant or has a small number of values.
> Consider the following query:
> {code:java}
> SELECT ename, job, RLIKE(ename, 'A.*'), RLIKE(ename, job || '.*')
> FROM emp
> {code}
> The first regular expression, '{{A.\*}}', is constant and can be compiled at
> prepare time or at the start of execution; the second regular expression,
> {{job || '.\*'}}, might vary from one row to the next. However if the {{job}}
> column has a small number of values it still might be beneficial to cache the
> compiled regular expression.
> If {{SqlFunctions.rlike}} could use a cache (mapping from {{String}} to
> {{{}java.util.regex.Pattern{}}}) then it would achieve benefits in both the
> constant and non-constant cases.
> The cache needs to:
> * be thread-safe (in case queries are executing using multiple threads),
> * return thread-safe objects (as is {{{}Pattern{}}}),
> * have bounded space (so that a query doesn't blow memory with 1 million
> distinct regular expressions),
> * disposed after the query has terminated,
> * (ideally) share with regexes of the same language in the same query,
> * not conflict with regexes of different languages in the same query.
> One possible implementation is to add an {{interface FunctionState}}, with
> subclasses including {{class RegexpCache}}, and if argument 1 of a function
> is a subclass of {{FunctionState}} the compiler would initialize the state in
> the generated code. The function can rely on the state argument being
> initialized, and being the same object from one call to the next. Example:
> {code:java}
> interface FunctionState {
> }
> class RegexpCache implements FunctionState {
> final Cache cache = ...;
> }
> {code}
> This change should install the cache for all applicable functions, including
> LIKE, ILIKE, RLIKE, SIMILAR, posix regex, REGEXP_REPLACE (MySQL, Oracle),
> REGEXP_CONTAINS (BigQuery), other BigQuery REGEXP_ functions, PARSE_URL,
> JSON_REPLACE, PARSE_TIMESTAMP.
> It can also be used for functions that have mutable state, e.g. {{RANDOM}}
> with and without a seed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5923) Some test cases in `SqlOperatorTest` violates the test fixture's design principle
[ https://issues.apache.org/jira/browse/CALCITE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759259#comment-17759259 ] Runkang He commented on CALCITE-5923: - The new Jira is CALCITE-5957. > Some test cases in `SqlOperatorTest` violates the test fixture's design > principle > - > > Key: CALCITE-5923 > URL: https://issues.apache.org/jira/browse/CALCITE-5923 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Minor > Labels: pull-request-available > > There are some test cases in `SqlOperatorTest` directly use the > `SqlOperatorFixtureImpl.DEFAULT` to get the `SqlOperatorFixture`, including > `SqlOperatorTest.testCast` and many other test cases related with `CAST` > operator. This causes that the result check is missing when execute > `CalciteSqlOperatorTest`, which should has result check. > This violates the design principle introduced by CALCITE-4885, which we > should alway use `SqlOperatorTest.fixture()` to get the `SqlOperatorFixture`. > This principle allows us to override`fixture()` method in subclasses to run > tests in a different environment. > So I think we should fix these related test cases to keep consistent with the > principle. -- 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 ] Runkang He updated CALCITE-5957: Summary: Valid DATE '1945-2-2' is not accepted due to regression (was: Validate DATE '1945-2-2' is not accepted due to regression) > 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 >Priority: Major > > 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] [Created] (CALCITE-5957) Validate DATE '1945-2-2' is not accepted due to regression
Runkang He created CALCITE-5957: --- Summary: Validate 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 DATE '1945-2-2' is a validate 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) Validate 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 ] Runkang He updated CALCITE-5957: Description: 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. (was: DATE '1945-2-2' is a validate 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.) > Validate 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 >Priority: Major > > 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-5923) Some test cases in `SqlOperatorTest` violates the test fixture's design principle
[ https://issues.apache.org/jira/browse/CALCITE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759257#comment-17759257 ] Runkang He commented on CALCITE-5923: - [~julianhyde] Thanks for clarifying the essence of the issue. I believe that Calcite accepted DATE '1945-2-2' before CALCITE-5678 but not afterwards, because the test is passed using avatica-1.23 after the result check is turned on in [Github CI|https://github.com/apache/calcite/pull/3364/checks?check_run_id=15852159948] of the PR's first commit. So this is a regression. I will open a new Jira for it. > Some test cases in `SqlOperatorTest` violates the test fixture's design > principle > - > > Key: CALCITE-5923 > URL: https://issues.apache.org/jira/browse/CALCITE-5923 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Minor > Labels: pull-request-available > > There are some test cases in `SqlOperatorTest` directly use the > `SqlOperatorFixtureImpl.DEFAULT` to get the `SqlOperatorFixture`, including > `SqlOperatorTest.testCast` and many other test cases related with `CAST` > operator. This causes that the result check is missing when execute > `CalciteSqlOperatorTest`, which should has result check. > This violates the design principle introduced by CALCITE-4885, which we > should alway use `SqlOperatorTest.fixture()` to get the `SqlOperatorFixture`. > This principle allows us to override`fixture()` method in subclasses to run > tests in a different environment. > So I think we should fix these related test cases to keep consistent with the > principle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
exception:
{code:java}
java.lang.AssertionError: Expected query to throw exception, but it did not;
query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must be
of the same type]
at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
at
org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
{code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
std map constructor:
{code:java}
public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
public SqlMapValueConstructor() {
super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
Pair<@Nullable RelDataType, @Nullable RelDataType> type =
getComponentTypes(
opBinding.getTypeFactory(), opBinding.collectOperandTypes());
--> we need explicit cast here
return SqlTypeUtil.createMapType(
opBinding.getTypeFactory(),
requireNonNull(type.left, "inferred key type"),
requireNonNull(type.right, "inferred value type"),
false);
}
}{code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
exception:
{code:java}
java.lang.AssertionError: Expected query to throw exception, but it did not;
query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must be
of the same type]
at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
at
org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
{code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
std map constructor:
{code:java}
public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
public SqlMapValueConstructor() {
super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
Pair<@Nullable RelDataType, @Nullable RelDataType> type =
getComponentTypes(
opBinding.getTypeFactory(), opBinding.collectOperandTypes());
--> we need explicit cast here
return SqlTypeUtil.createMapType(
opBinding.getTypeFactory(),
requireNonNull(type.left, "inferred key type"),
requireNonNull(type.right, "inferred value type"),
false);
}
}{code}
we need to fix the std array/map and spark array/map functions. and add more
test cases to cover all the array functions.
was:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.ja
[jira] [Comment Edited] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759235#comment-17759235
]
Jiajun Xie edited comment on CALCITE-5944 at 8/26/23 10:34 AM:
---
Would anyone please review it?
https://github.com/apache/calcite/pull/3382
was (Author: jiajunbernoulli):
Would anyone please review it?
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5944) Add metadata for Sample
[
https://issues.apache.org/jira/browse/CALCITE-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759235#comment-17759235
]
Jiajun Xie commented on CALCITE-5944:
-
Would anyone please review it?
> Add metadata for Sample
> ---
>
> Key: CALCITE-5944
> URL: https://issues.apache.org/jira/browse/CALCITE-5944
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Minor
> Labels: pull-request-available
>
> For the sql
> {code:java}
> select * from emp tablesample system(20) {code}
> `mq.getRowCount(rel)` is null, but we can return `inputRowCount * 0.2`.
>
> Some metadata need to be implemented.
> * RelMdAllPredicates
> * RelMdColumnOrigins
> * RelMdExpressionLineage
> * RelMdMaxRowCount
> * RelMdMinRowCount
> * RelMdPredicates
> * RelMdRowCount
> Some metadata have been implemented.
> * RelMdTableReferences
> * RelMdNodeTypes
> Some metadabata not need to be implemented.
> * RelMdColumnUniqueness (Handle SingleRel)
> * RelMdDistribution (Handle SingleRel)
> * RelMdDistinctRowCount（Handle RelNode）
> * RelMdExplainVisibility（Only TableScan）
> * RelMdLowerBoundCost（Handle RelNode）
> * RelMdMemory（Handle RelNode）
> * RelMdParallelism（Handle RelNode）
> * RelMdPercentageOriginalRows（Handle RelNode）
> * RelMdPopulationSize（Handle RelNode）
> * RelMdSelectivity（Must have predicate）
> * RelMdSize（Handle RelNode）
> * RelMdUniqueKeys（Handle SingleRel）
--
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&focusedCommentId=17759231#comment-17759231
]
Jiajun Xie commented on CALCITE-5956:
-
IMO: The core module supports too many parsing methods, which can easily lead
to confusion.
Map has two parameters, which are quite special. So we need `Map` in core
module.
{{But `ARRAY`}} and `{{{}MULITSET` are not necessary.{}}}
I suggest supporting it in the babel module
> 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] [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&focusedCommentId=17759225#comment-17759225
]
hongyu guo commented on CALCITE-5956:
-
Hi, [~julianhyde], thank you for your comment.
I will present my ideas for this case in two ways:
- The SQL standard syntax cannot represent MAP types, so implementing dialects
similar to {{ARRAY}} can better support {{MAP}} syntax in the future.
(As discussed in CALCITE-5570)
- I think this is compatible with a grammar, which does not have a destructive
effect on Calcite, but rather enhances it.
> 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)
