[jira] [Resolved] (CALCITE-6317) Incorrect constant replacement when group keys are NULL
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6317.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/fe0da064dc3081b140e3c84e109aed63f202a4af
> Incorrect constant replacement when group keys are NULL
> ---
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6317) Incorrect constant replacement when group keys are NULL
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu updated CALCITE-6317:
-
Summary: Incorrect constant replacement when group keys are NULL (was:
Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound)
> Incorrect constant replacement when group keys are NULL
> ---
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6278) Add REGEXP, REGEXP_LIKE function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongyu guo resolved CALCITE-6278. - Fix Version/s: 1.37.0 Assignee: EveyWu Resolution: Fixed Fixed in [d8804b46|https://github.com/apache/calcite/commit/d8804b46870d9d1ba2bcfafc0646ce206647625c]. Thanks [~eveywu]. > Add REGEXP, REGEXP_LIKE function (enabled in Spark library) > > > Key: CALCITE-6278 > URL: https://issues.apache.org/jira/browse/CALCITE-6278 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Assignee: EveyWu >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > Attachments: image-2024-03-07-09-32-27-002.png, > image-2024-03-09-11-13-49-064.png, image-2024-03-09-11-37-27-816.png, > image-2024-03-09-11-38-08-797.png > > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function > [REGEXP|https://spark.apache.org/docs/latest/api/sql/index.html#regexp], > [REGEXP_LIKE|https://spark.apache.org/docs/latest/api/sql/index.html#regexp_like] > # Since this function has the same implementation as the Spark > [RLIKE|https://spark.apache.org/docs/latest/api/sql/index.html#rlike] > function, the implementation can be directly reused. > # -Since Spark 2.0, string literals (including regex patterns) are unescaped > in SQL parser, also fix this bug in calcite.- > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825487#comment-17825487
]
Jiajun Xie edited comment on CALCITE-6317 at 3/12/24 1:55 AM:
--
For calcite user,
the message maybe better: "Incorrect constant replacement when the aggregation
result is null".
was (Author: jiajunbernoulli):
For calcite user,
the message maybe better: "Incorrect constant replacement when the aggregation
result is null".
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825487#comment-17825487
]
Jiajun Xie commented on CALCITE-6317:
-
For calcite user,
the message maybe better: "Incorrect constant replacement when the aggregation
result is null".
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6322) Casts to DECIMAL types are ignored
Mihai Budiu created CALCITE-6322:
Summary: Casts to DECIMAL types are ignored
Key: CALCITE-6322
URL: https://issues.apache.org/jira/browse/CALCITE-6322
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Mihai Budiu
The following SqlOperatorTest fails:
{code:java}
f.checkScalar("CAST(1.123 AS DECIMAL(4, 0))", "1.0", "DECIMAL(4, 0) NOT NULL");
{code}
The result computed by Calcite is 1.123, ignoring the scale of the DECIMAL
result.
Spark, Postgres, MySQL all return 1.0.
I have marked this as a major bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6321) Add copy(List constants) method to Window class.
Thomas D'Silva created CALCITE-6321: --- Summary: Add copy(List constants) method to Window class. Key: CALCITE-6321 URL: https://issues.apache.org/jira/browse/CALCITE-6321 Project: Calcite Issue Type: Improvement Reporter: Thomas D'Silva -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6262) CURRENT_TIMESTAMP(P) ignores DataTypeSystem#getMaxPrecision
[
https://issues.apache.org/jira/browse/CALCITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6262.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/b0034c9ed885644e22edc92e8ab939128ee6b615
Thank you [~jduong] for the fix
> CURRENT_TIMESTAMP(P) ignores DataTypeSystem#getMaxPrecision
> ---
>
> Key: CALCITE-6262
> URL: https://issues.apache.org/jira/browse/CALCITE-6262
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Adam Kennedy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Datetime precision parameters are incorrectly validated against the DEFAULT
> maximum date time precision (3) instead of against the maximum date time
> precision configured by the DateTimeSystem#getMaxPrecision method.
> This breaks, at minimum, CURRENT_TIMESTAMP(P > 3) when precisions greater
> than 3 are supported by the system.
> The culprit is the following method in SqlAbstractTimeFunction
>
> {code:java}
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> // REVIEW jvs 20-Feb-2005: Need to take care of time zones.
> int precision = 0;
> if (opBinding.getOperandCount() == 1) {
> RelDataType type = opBinding.getOperandType(0);
> if (SqlTypeUtil.isNumeric(type)) {
> precision = getOperandLiteralValueOrThrow(opBinding, 0,
> Integer.class);
> }
> }
> assert precision >= 0;
> if (precision > SqlTypeName.MAX_DATETIME_PRECISION) {
> throw opBinding.newError(
> RESOURCE.argumentMustBeValidPrecision(
> opBinding.getOperator().getName(), 0,
> SqlTypeName.MAX_DATETIME_PRECISION));
> }
> return opBinding.getTypeFactory().createSqlType(typeName, precision);
> }{code}
>
>
> The correct value is readily accessible from
>
> {code:java}
> opBinding.getTypeFactory().getTypeSystem().getMaxPrecision(typeName){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6283) Function ARRAY_APPEND with a NULL array argument crashes with NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6283.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/90beb01b0713a010167aeb2c810ffebccf3aa3e1
> Function ARRAY_APPEND with a NULL array argument crashes with
> NullPointerException
> --
>
> Key: CALCITE-6283
> URL: https://issues.apache.org/jira/browse/CALCITE-6283
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The following test added to SqlOperatorTest:
> {code:java}
> f.checkNull("array_append(null, 2)");
> {code}
> causes Calcite to crash with the following stack trace:
> {code}
> java.lang.NullPointerException: componentType is null for NULL
> at java.base/java.util.Objects.requireNonNull(Objects.java:347)
> at
> org.apache.calcite.sql.type.NonNullableAccessors.getComponentTypeOrThrow(NonNullableAccessors.java:52)
> at
> org.apache.calcite.sql.type.ArrayElementOperandTypeChecker.checkOperandTypes(ArrayElementOperandTypeChecker.java:49)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:761)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:498)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:347)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu updated CALCITE-6317:
-
Fix Version/s: 1.37.0
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu reassigned CALCITE-6317:
Assignee: Mihai Budiu
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6317:
Labels: pull-request-available (was: )
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6308) Add PostgreSQL functions up to PostgreSQL v14
[
https://issues.apache.org/jira/browse/CALCITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825411#comment-17825411
]
James Duong commented on CALCITE-6308:
--
[~caicancai] , would it be possible to list the sub-issues from this issue that
you're currently working on?
I saw this
https://issues.apache.org/jira/browse/CALCITE-6252?focusedCommentId=17817719=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17817719
as well, but I think the current implementation of TO_CHAR doesn't support
PostgreSQL's format strings which is why I raised CALCITE-6315
> Add PostgreSQL functions up to PostgreSQL v14
> -
>
> Key: CALCITE-6308
> URL: https://issues.apache.org/jira/browse/CALCITE-6308
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: James Duong
>Priority: Minor
>
> Support the following PostgreSQL functions for parity with PostgreSQL 14:
> * REGEXP_LIKE
> ** The Spark version of this is being implemented in CALCITE-6278
> ** The PostgreSQL version requires supporting a 3-arg version that takes in
> flags.
> * REGEXP_REPLACE
> ** There is an existing implementation.
> ** PostgreSQL requires supporting an optional extra flags argument
> * DATE_PART
> ** PostgreSQL and Redshift let the date_part parameter be a string instead
> of a just an enum-like identifier (eg DATE_PART('year', ...) and
> DATE_PART(year, ...) are both supported.
> ** SQL Server does not support using a string here.
> * LOG
> ** We have the BigQuery implementation which has a 1-arg overload that uses
> base e (ln), and a 2-arg overload which is LOG(value, base)
> ** PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the
> order reversed – LOG(base, value)
> * POW
> ** Our existing implementation always returns double.
> ** PostgreSQL allows returning a numeric instead of a double when inputs are
> numeric. Not sure if this makes sense though.
> * RANDOM
> ** This is an alias for RAND(), except it should not support passing in a
> seed.
> * TO_CHAR
> * TO_DATE
> * TO_TIMESTAMP
> ** PostgreSQL supports different format strings than the version we have
> implemented.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6312) Support PostgreSQL LOG
[ https://issues.apache.org/jira/browse/CALCITE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanner Clary reassigned CALCITE-6312: - Assignee: Caican Cai > Support PostgreSQL LOG > -- > > Key: CALCITE-6312 > URL: https://issues.apache.org/jira/browse/CALCITE-6312 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: Caican Cai >Priority: Minor > > * We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6312) Support PostgreSQL LOG
[ https://issues.apache.org/jira/browse/CALCITE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825410#comment-17825410 ] Tanner Clary commented on CALCITE-6312: --- [~jduong] [~caicancai] done > Support PostgreSQL LOG > -- > > Key: CALCITE-6312 > URL: https://issues.apache.org/jira/browse/CALCITE-6312 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: Caican Cai >Priority: Minor > > * We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6312) Support PostgreSQL LOG
[ https://issues.apache.org/jira/browse/CALCITE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825404#comment-17825404 ] James Duong commented on CALCITE-6312: -- [~caicancai] , it seems reasonable to make this work part of CALCITE-6259. I can't assign JIRAs though. Perhaps [~tanclary] ? > Support PostgreSQL LOG > -- > > Key: CALCITE-6312 > URL: https://issues.apache.org/jira/browse/CALCITE-6312 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > > * We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-2980) Implement the FORMAT clause of the CAST operator
[
https://issues.apache.org/jira/browse/CALCITE-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerin John reassigned CALCITE-2980:
---
Assignee: Jerin John
> Implement the FORMAT clause of the CAST operator
>
>
> Key: CALCITE-2980
> URL: https://issues.apache.org/jira/browse/CALCITE-2980
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
>
> SQL:2016 adds an optional {{FORMAT format}} clause to the {{CAST}} operator.
> It is a standard way to do what functions like {{TO_DATE}}, {{TO_NUMBER}},
> {{TO_CHAR}}, {{TO_TIMESTAMP}} have done in an ad hoc way (and with differing
> specifications among databases).
> Here is an example:
> {code:java}
> cast('01-05-2017' as date format 'DD-MM-')
> {code}
> The following paragraphs are copied from IMPALA-4018, which describes
> implementing this in Impala. (That case also describes cases where the
> implementations of {{TO_TIMESTAMP}} etc. in Hive, Impala, Oracle and
> PostgreSQL are not consistent with each other. We should take note as we
> implement these functions in Calcite.)
> SQL:2016 defines the following datetime templates
> {noformat}
> ::=
> { }...
> ::=
>
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> ::=
> | YYY | YY | Y
> ::=
> | RR
> ::=
> MM
> ::=
> DD
> ::=
> DDD
> ::=
> HH | HH12
> ::=
> HH24
> ::=
> MI
> ::=
> SS
> ::=
> S
> ::=
> FF1 | FF2 | FF3 | FF4 | FF5 | FF6 | FF7 | FF8 | FF9
> ::=
> A.M. | P.M.
> ::=
> TZH
> ::=
> TZM
> {noformat}
> SQL:2016 also introduced the {{FORMAT}} clause for {{CAST}} which is the
> standard way to do string <> datetime conversions
> {noformat}
> ::=
> CAST
>AS
> [ FORMAT ]
>
> ::=
>
> |
> ::=
>
> |
> ::=
>
> {noformat}
> For example:
> {noformat}
> CAST( AS [FORMAT ])
> CAST( AS [FORMAT ])
> cast(dt as string format 'DD-MM-')
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6278) Add REGEXP, REGEXP_LIKE function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825227#comment-17825227 ] EveyWu commented on CALCITE-6278: -- done, CALCITE-6320 has been added to follow up. > Add REGEXP, REGEXP_LIKE function (enabled in Spark library) > > > Key: CALCITE-6278 > URL: https://issues.apache.org/jira/browse/CALCITE-6278 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > Attachments: image-2024-03-07-09-32-27-002.png, > image-2024-03-09-11-13-49-064.png, image-2024-03-09-11-37-27-816.png, > image-2024-03-09-11-38-08-797.png > > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function > [REGEXP|https://spark.apache.org/docs/latest/api/sql/index.html#regexp], > [REGEXP_LIKE|https://spark.apache.org/docs/latest/api/sql/index.html#regexp_like] > # Since this function has the same implementation as the Spark > [RLIKE|https://spark.apache.org/docs/latest/api/sql/index.html#rlike] > function, the implementation can be directly reused. > # -Since Spark 2.0, string literals (including regex patterns) are unescaped > in SQL parser, also fix this bug in calcite.- > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6320) Parse SQL with Hive-style and Spark-style unescaped character literals
[ https://issues.apache.org/jira/browse/CALCITE-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] EveyWu updated CALCITE-6320: Description: # Since Spark 2.0, string literals (including regex patterns) are unescaped in the parser phase, details in [AstBuilder|[https://github.com/apache/spark/blob/76b1c122cb7d77e8f175b25b935b9296a669d5d8/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/parser/AstBuilder.scala#L2876C1-L2882C4]] # In Hive, unescape in the node normalization phase(`Dispatcher#dispatch`).[StrExprProcessor|[https://github.com/apache/hive/blob/03a76ac70370fb94a78b00496ec511e671c652f2/ql/src/java/org/apache/hadoop/hive/ql/parse/type/TypeCheckProcFactory.java#L403C1-L405C17]] is the processor for processing string unescape. > Parse SQL with Hive-style and Spark-style unescaped character literals > -- > > Key: CALCITE-6320 > URL: https://issues.apache.org/jira/browse/CALCITE-6320 > Project: Calcite > Issue Type: Bug >Reporter: EveyWu >Priority: Minor > > # Since Spark 2.0, string literals (including regex patterns) are unescaped > in the parser phase, details in > [AstBuilder|[https://github.com/apache/spark/blob/76b1c122cb7d77e8f175b25b935b9296a669d5d8/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/parser/AstBuilder.scala#L2876C1-L2882C4]] > # In Hive, unescape in the node normalization > phase(`Dispatcher#dispatch`).[StrExprProcessor|[https://github.com/apache/hive/blob/03a76ac70370fb94a78b00496ec511e671c652f2/ql/src/java/org/apache/hadoop/hive/ql/parse/type/TypeCheckProcFactory.java#L403C1-L405C17]] > is the processor for processing string unescape. > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6320) Parse SQL with Hive-style and Spark-style unescaped character literals
EveyWu created CALCITE-6320: Summary: Parse SQL with Hive-style and Spark-style unescaped character literals Key: CALCITE-6320 URL: https://issues.apache.org/jira/browse/CALCITE-6320 Project: Calcite Issue Type: Bug Reporter: EveyWu -- This message was sent by Atlassian Jira (v8.20.10#820010)
