[jira] [Comment Edited] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256823#comment-17256823 ] JIasen Sheng edited comment on CALCITE-4188 at 12/31/20, 7:46 AM: -- I will remove SqlFieldAccessCorrelate. And it is necessary to distinguish between implict and Explicit. Explicit dynamic parameters are generated in the sql parsing stage and assigned the corresponding index. The implicit dynamic parameters do not participate in this stage. Therefore, a unified index value cannot be generated and can only be processed according to the corresponding correlate during unparse. If we reuse sqlDynamicParam, we also need to make corresponding distinctions internally. SELECT * FROM SCOTT.emp WHERE empno SELECT * FROM SCOTT.emp WHERE ename =? And empno SELECT * FROM SCOTT.emp WHERE ename =? And empno support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256823#comment-17256823 ] JIasen Sheng edited comment on CALCITE-4188 at 12/31/20, 7:34 AM: -- I will remove SqlFieldAccessCorrelate. And it is necessary to distinguish between implict and Explicit. Explicit dynamic parameters are generated in the sql parsing stage and assigned the corresponding index. The implicit dynamic parameters do not participate in this stage. Therefore, a unified index value cannot be generated and can only be processed according to the corresponding correlate during unparse. If we reuse sqlDynamicParam, we also need to make corresponding distinctions internally. Considering the large differences in processing, I think it would be better to use a new class. SELECT * FROM SCOTT.emp WHERE empno SELECT * FROM SCOTT.emp WHERE ename =? And empno SELECT * FROM SCOTT.emp WHERE ename =? And empno support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256823#comment-17256823 ] JIasen Sheng edited comment on CALCITE-4188 at 12/31/20, 7:33 AM: -- I will remove SqlFieldAccessCorrelate. And it is necessary to distinguish between the implict and Explicit. Explicit dynamic parameters are generated in the sql parsing stage and assigned the corresponding index. The implicit dynamic parameters do not participate in this stage. Therefore, a unified index value cannot be generated and can only be processed according to the corresponding correlate during unparse. If we reuse sqlDynamicParam, we also need to make corresponding distinctions internally. Considering the large differences in processing, I think it would be better to use a new class. SELECT * FROM SCOTT.emp WHERE empno SELECT * FROM SCOTT.emp WHERE ename =? And empno SELECT * FROM SCOTT.emp WHERE ename =? And empno support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256849#comment-17256849
]
Rui Wang commented on CALCITE-4434:
---
[~julianhyde]
Thanks for your suggestions. I probably should find a better way for me to
merge commits :).
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> ...
> Suppressed: java.lang.NullPointerException: SqlTypeFamily for
> RecordType(INTEGER EXPR$0, VARCHAR(9)
[jira] [Commented] (CALCITE-4349) Support GROUP_CONCAT aggregate function for MySQL
[
https://issues.apache.org/jira/browse/CALCITE-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256837#comment-17256837
]
Zhen Wang commented on CALCITE-4349:
want some discussion here, the overall implementation would be something like
below
https://github.com/apache/calcite/compare/master...zinking:CALCITE-4349?expand=1
what should 'SEPARATOR' be in the parsing result ? an operator call ? or just
some literal? didn't manage to find something similar in the code base.
[~julianhyde]
> Support GROUP_CONCAT aggregate function for MySQL
> -
>
> Key: CALCITE-4349
> URL: https://issues.apache.org/jira/browse/CALCITE-4349
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Support the {{GROUP_CONCAT}} aggregate function for MySQL. Here is the
> [syntax|https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html#function_group-concat]:
> {noformat}
> GROUP_CONCAT([DISTINCT] expr [,expr ...]
> [ORDER BY {unsigned_integer | col_name | expr}
> [ASC | DESC] [,col_name ...]]
> [SEPARATOR str_val])
> {noformat}
>
> {{GROUP_CONCAT}} is analogous to {{LISTAGG}} (see CALCITE-2754) (and also to
> BigQuery and PostgreSQL's {{STRING_AGG}}, see CALCITE-4335). For example, the
> query
> {code:java}
> SELECT deptno, GROUP_CONCAT(ename ORDER BY empno SEPARATOR ';')
> FROM Emp
> GROUP BY deptno
> {code}
> is equivalent to (and in Calcite's algebra would be desugared to)
> {code:java}
> SELECT deptno, LISTAGG(ename, ';') WITHIN GROUP (ORDER BY empno)
> FROM Emp
> GROUP BY deptno
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256823#comment-17256823 ] JIasen Sheng commented on CALCITE-4188: --- I tried to convert correlate to sqlDynamicParam already.Explicit dynamic parameters are generated in the sql parsing stage and assigned the corresponding index. The implicitly dynamic parameters do not participate in this stage. Therefore, a unified index value cannot be generated and can only be processed according to the corresponding correlate during unparse. If we reuse sqlDynamicParam, we also need to make corresponding distinctions internally. Considering the large differences in processing, I think it would be better to use a new class. SELECT * FROM SCOTT.emp WHERE empno SELECT * FROM SCOTT.emp WHERE ename =? And empno support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4452) The query column is allowed not in the group by in MySQL
Quan Chao created CALCITE-4452: -- Summary: The query column is allowed not in the group by in MySQL Key: CALCITE-4452 URL: https://issues.apache.org/jira/browse/CALCITE-4452 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.26.0 Reporter: Quan Chao Fix For: next In MySQL， query column can be not contained in group by columns，the final column value is first column value in group CREATE TABLE `a` ( `id` int(11) DEFAULT NULL, `a` int(11) DEFAULT NULL, `c` varchar(10) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8； CREATE TABLE `b` ( `id` int(11) DEFAULT NULL, `a` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 select concat(a.a,b.a) from a join b on a.a=b.a group by a.c; Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Expression 'a.a' is not being groupedCaused by: org.apache.calcite.sql.validate.SqlValidatorException: Expression 'a.a' is not being grouped at sun.reflect.GeneratedConstructorAccessor45.newInstance(Unknown Source) ~[?:?] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_252] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_252] at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:560) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:868) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5043) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:113) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:320) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:879) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlAsOperator.acceptCall(SqlAsOperator.java:121) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:209) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:218) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4263) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4234) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3474) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1067) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1041) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:232) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1016) ~[calcite-core-1.26.0.jar:1.26.0] at org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:724) ~[calcite-core-1.26.0.jar:1.26.0] at
[jira] [Resolved] (CALCITE-4367) Incorrect documentation for Avatica JSON request/response signatures
[
https://issues.apache.org/jira/browse/CALCITE-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-4367.
-
Fix Version/s: avatica-1.18.0
Resolution: Fixed
> Incorrect documentation for Avatica JSON request/response signatures
>
>
> Key: CALCITE-4367
> URL: https://issues.apache.org/jira/browse/CALCITE-4367
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: John Bodley
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: avatica-1.18.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I noticed a few inconsistencies between what is documented in the [Avatica
> JSON Reference|https://calcite.apache.org/avatica/docs/json_reference.html]
> and what the Avatica JDBC driver provides, specifically:
> # The {{DatabasePropertyRequest}} was missing the {{connection_id}} field in
> the example signature.
> # `RpcMetadata` is actually a response as opposed to a miscellaneous type per
> [here|https://github.com/apache/calcite-avatica/blob/4b7eee5bf430b916c7c07897b6f60d2b6b6dabb7/core/src/main/protobuf/responses.proto#L114-L116]
> and thus requires a {{response}} field. Note I'm not certain if this was
> intentional, i.e., it being a response, however it it is it seems that it
> should be renamed to {{RpcMetadataResponse}} for consistency.
> # The supplied {{ConnectionProperties}} contains an undocumented {{dirty}}
> field ({{is_dirty}} for protobuf).
> # For the {{SchemasRequest}} the {{catalog}} and {{schemaPattern}} are
> optional rather than required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4451) Group by is always case sensitive， but in mysql some Collate like *_ci is case insensitive
Quan Chao created CALCITE-4451: -- Summary: Group by is always case sensitive， but in mysql some Collate like *_ci is case insensitive Key: CALCITE-4451 URL: https://issues.apache.org/jira/browse/CALCITE-4451 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.26.0, 1.25.0, 1.24.0, 1.23.0 Reporter: Quan Chao Fix For: next CREATE TABLE `a` ( `id` int(11) DEFAULT NULL, `a` int(11) DEFAULT NULL, `c` varchar(10) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `b` ( `id` int(11) DEFAULT NULL, `a` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into a values(1,1,'a'),(2,2,'B'),(3,3,'A'),(4,4,'b'); insert into b values(1,1),(2,2),(3,3),(4,4); in Calcite: mysql> select concat(a.c,1) from a join b on a.a=b.a group by a.c; +---+ | concat(a.c,1) | +---+ | A1 | | a1 | | B1 | | b1 | +---+ 4 rows in set (0.13 sec) in Mysql: mysql> select collation(a.c) from a limit 1; +-+ | collation(a.c) | +-+ | utf8_general_ci | +-+ 1 row in set (0.00 sec) mysql> select concat(a.c,1) from a join b on a.a=b.a group by a.c; +---+ | concat(a.c,1) | +---+ | a1 | | B1 | +---+ 2 rows in set (0.00 sec) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4450) ElasticSearch query with varchar literal projection fails with JsonParseException
[
https://issues.apache.org/jira/browse/CALCITE-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4450:
Labels: pull-request-available (was: )
> ElasticSearch query with varchar literal projection fails with
> JsonParseException
> -
>
> Key: CALCITE-4450
> URL: https://issues.apache.org/jira/browse/CALCITE-4450
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A query that contains varchar literals in projection fails for ElasticSearch
> adapter. Simple test case to reproduce the issue:
> {code:java}
> @Test void projectionStringLiteral() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query(
> String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
> + "from \"elastic\".\"%s\"", NAME))
> .returns("lit=foo\n");
> }
> {code}
> Error:
> {noformat}
> Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected
> character ('f' (code 102)): was expecting comma to separate Object entries
> at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
> "a":{"script": "params._source.a"}}}"; line: 1, column: 40]
> at
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
> {noformat}
> The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do
> not escape literal quotes, and forms the following string: {{"lit":""foo""}}
> that cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4450) ElasticSearch query with varchar literal projection fails with JsonParseException
[
https://issues.apache.org/jira/browse/CALCITE-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vova Vysotskyi updated CALCITE-4450:
Summary: ElasticSearch query with varchar literal projection fails with
JsonParseException (was: Query on ElasticSearch table that projects varchar
literal fails with JsonParseException)
> ElasticSearch query with varchar literal projection fails with
> JsonParseException
> -
>
> Key: CALCITE-4450
> URL: https://issues.apache.org/jira/browse/CALCITE-4450
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Fix For: 1.27.0
>
>
> A query that contains varchar literals in projection fails for ElasticSearch
> adapter. Simple test case to reproduce the issue:
> {code:java}
> @Test void projectionStringLiteral() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query(
> String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
> + "from \"elastic\".\"%s\"", NAME))
> .returns("lit=foo\n");
> }
> {code}
> Error:
> {noformat}
> Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected
> character ('f' (code 102)): was expecting comma to separate Object entries
> at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
> "a":{"script": "params._source.a"}}}"; line: 1, column: 40]
> at
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
> {noformat}
> The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do
> not escape literal quotes, and forms the following string: {{"lit":""foo""}}
> that cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4448) Use TableMacro user-defined table functions with QueryableTable
[
https://issues.apache.org/jira/browse/CALCITE-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vova Vysotskyi updated CALCITE-4448:
Fix Version/s: 1.27.0
> Use TableMacro user-defined table functions with QueryableTable
> ---
>
> Key: CALCITE-4448
> URL: https://issues.apache.org/jira/browse/CALCITE-4448
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Calcite widely uses {{QueryableTable}} during the query execution, and it
> also provides the capabilities for creating user-defined table functions
> using {{TableMacro}}. But currently, it is impossible to use such
> user-defined table functions with the queriable table. Here is the sample
> test that demonstrates this issue:
> {code:java}
> @Test void testQueryableTableWithTableMacro() throws SQLException {
> TableMacro tableMacro = new TableMacro() {
> @Override
> public TranslatableTable apply(List arguments) {
> return new TableInRootSchemaTest.SimpleTable();
> }
> @Override
> public List getParameters() {
> return Collections.emptyList();
> }
> };
> try (Connection connection =
> DriverManager.getConnection("jdbc:calcite:")) {
> CalciteConnection calciteConnection =
> connection.unwrap(CalciteConnection.class);
> SchemaPlus rootSchema = calciteConnection.getRootSchema();
> SchemaPlus schema = rootSchema.add("s", new AbstractSchema());
> schema.add("simple", tableMacro);
> ResultSet resultSet = connection.createStatement().executeQuery(
> "select * from table(\"s\".\"simple\"())");
> assertThat(CalciteAssert.toString(resultSet),
> equalTo("A=\"foo\",B=5\n"
> + "A=\"bar\",B=4\n"
> + "A=\"foo\",B=3\n"));
> }
> }
> {code}
> This test fails with the following exception when trying to convert
> expressions to the executable code:
> {noformat}
> Error while executing SQL "select * from table("s"."simple"())": Unable to
> implement EnumerableTableScan(table=[[s, simple]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 0
> java.sql.SQLException: Error while executing SQL "select * from
> table("s"."simple"())": Unable to implement EnumerableTableScan(table=[[s,
> simple]]): rowcount = 100.0, cumulative cost = {100.0 rows, 101.0 cpu, 0.0
> io}, id = 0
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.JdbcTest.testQueryableTableWithTableMacro(JdbcTest.java:525)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
[jira] [Updated] (CALCITE-4450) Query on ElasticSearch table that projects varchar literal fails with JsonParseException
[
https://issues.apache.org/jira/browse/CALCITE-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vova Vysotskyi updated CALCITE-4450:
Fix Version/s: 1.27.0
> Query on ElasticSearch table that projects varchar literal fails with
> JsonParseException
>
>
> Key: CALCITE-4450
> URL: https://issues.apache.org/jira/browse/CALCITE-4450
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Fix For: 1.27.0
>
>
> A query that contains varchar literals in projection fails for ElasticSearch
> adapter. Simple test case to reproduce the issue:
> {code:java}
> @Test void projectionStringLiteral() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query(
> String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
> + "from \"elastic\".\"%s\"", NAME))
> .returns("lit=foo\n");
> }
> {code}
> Error:
> {noformat}
> Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected
> character ('f' (code 102)): was expecting comma to separate Object entries
> at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
> "a":{"script": "params._source.a"}}}"; line: 1, column: 40]
> at
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
> {noformat}
> The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do
> not escape literal quotes, and forms the following string: {{"lit":""foo""}}
> that cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4450) Query on ElasticSearch table that projects varchar literal fails with JsonParseException
Vova Vysotskyi created CALCITE-4450:
---
Summary: Query on ElasticSearch table that projects varchar
literal fails with JsonParseException
Key: CALCITE-4450
URL: https://issues.apache.org/jira/browse/CALCITE-4450
Project: Calcite
Issue Type: Bug
Affects Versions: 1.26.0
Reporter: Vova Vysotskyi
Assignee: Vova Vysotskyi
A query that contains varchar literals in projection fails for ElasticSearch
adapter. Simple test case to reproduce the issue:
{code:java}
@Test void projectionStringLiteral() {
CalciteAssert.that()
.with(newConnectionFactory())
.query(
String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
+ "from \"elastic\".\"%s\"", NAME))
.returns("lit=foo\n");
}
{code}
Error:
{noformat}
Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected character
('f' (code 102)): was expecting comma to separate Object entries
at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
"a":{"script": "params._source.a"}}}"; line: 1, column: 40]
at
com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
{noformat}
The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do not
escape literal quotes, and forms the following string: {{"lit":""foo""}} that
cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4446) Implement three-valued logic for SEARCH operator
[
https://issues.apache.org/jira/browse/CALCITE-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256678#comment-17256678
]
Julian Hyde edited comment on CALCITE-4446 at 12/30/20, 7:24 PM:
-
After this change, there will be 3 special Sarg values (implemented by {{class
SpecialSarg}}, a private sub-class of {{class Sarg}}) whose range is empty and
therefore return {{FALSE}} for all non-{{NULL}} values, and respectively return
{{FALSE}}, {{TRUE}}, {{UNKNOWN}} for the {{NULL}} value. Similarly, there are 3
special Sarg values whose range is everything and therefore return {{TRUE}} for
all non-{{NULL}} values, and respectively return {{FALSE}}, {{TRUE}},
{{UNKNOWN}} for the {{NULL}} value.
Consider the expression "{{x < 3 AND x > 5}}". It evaluates to {{FALSE}} for
all non-{{NULL}} values of {{x}}, and {{UNKNOWN}} if {{x}} is {{NULL}}. We
simplify to one of the aforementioned special Sarg values.
How should we convert that Sarg value back to SQL? We could generate "{{CASE
WHEN x IS NULL THEN UNKNOWN ELSE FALSE END}}" but we instead generate the more
concise {{"x <> x"}}.
was (Author: julianhyde):
After this change, there will be 3 special Sarg values (implemented by {{class
SpecialSarg}}, a private sub-class of {{class Sarg}}) whose range is empty and
therefore return {{FALSE}} for all non-{{NULL}} values, and respectively return
{{FALSE}}, {{TRUE}}, {{UNKNOWN}} for the {{NULL}} value. Similarly, there are 3
special Sarg values whose range is everything and therefore return {{TRUE}} for
all non-{{NULL}} values, and respectively return {{FALSE}}, {{TRUE}},
{{UNKNOWN}} for the {{NULL}} value.
Consider the expression "{{x < 3 AND x > 5}}". It evaluates to {{FALSE}} for
all non-{{NULL}} values of {{x}}, and {{UNKNOWN}} if {{x}} is {{NULL}}. We
simplify to one of the aforementioned special Sarg values.
How should we convert that Sarg value back to SQL? We could generate "{{CASE
WHEN x IS NULL THEN UKNOWN ELSE FALSE END}}" but we instead generate the more
concise {{"x <> x"}}.
> Implement three-valued logic for SEARCH operator
> -
>
> Key: CALCITE-4446
> URL: https://issues.apache.org/jira/browse/CALCITE-4446
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Implement three-valued logic for SEARCH operator.
> Consider the expression {{x IN (10, 20)}}, which we might represent as
> {{SEARCH(x, Sarg(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
> for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
> of the above.
> Here are the 3 variants:
> * {{Sarg(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}}
> TRUE
> * {{Sarg(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
> * {{Sarg(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
> FALSE
> Currently {{class Sarg}} has a field {{boolean containsNull}} which deals
> with the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
> unknownAs}} (which has 3 values) will allow us to represent the third. The
> new representation is symmetrical under negation, which de Morgan's law
> suggests is a good thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4446) Implement three-valued logic for SEARCH operator
[
https://issues.apache.org/jira/browse/CALCITE-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256678#comment-17256678
]
Julian Hyde commented on CALCITE-4446:
--
After this change, there will be 3 special Sarg values (implemented by {{class
SpecialSarg}}, a private sub-class of {{class Sarg}}) whose range is empty and
therefore return {{FALSE}} for all non-{{NULL}} values, and respectively return
{{FALSE}}, {{TRUE}}, {{UNKNOWN}} for the {{NULL}} value. Similarly, there are 3
special Sarg values whose range is everything and therefore return {{TRUE}} for
all non-{{NULL}} values, and respectively return {{FALSE}}, {{TRUE}},
{{UNKNOWN}} for the {{NULL}} value.
Consider the expression "{{x < 3 AND x > 5}}". It evaluates to {{FALSE}} for
all non-{{NULL}} values of {{x}}, and {{UNKNOWN}} if {{x}} is {{NULL}}. We
simplify to one of the aforementioned special Sarg values.
How should we convert that Sarg value back to SQL? We could generate "{{CASE
WHEN x IS NULL THEN UKNOWN ELSE FALSE END}}" but we instead generate the more
concise {{"x <> x"}}.
> Implement three-valued logic for SEARCH operator
> -
>
> Key: CALCITE-4446
> URL: https://issues.apache.org/jira/browse/CALCITE-4446
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Implement three-valued logic for SEARCH operator.
> Consider the expression {{x IN (10, 20)}}, which we might represent as
> {{SEARCH(x, Sarg(10, 20))}}. Suppose we invoke this with a value of {{NULL}}
> for {{x}}. Do we want it to return UNKNOWN, FALSE or TRUE? The answer is: all
> of the above.
> Here are the 3 variants:
> * {{Sarg(10, 20, UNKNOWN AS TRUE)}}: {{x IS NULL OR x IN (10, 20)}}
> TRUE
> * {{Sarg(10, 20, UNKNOWN AS UNKNOWN)}}: {{x IN (10, 20)}} UNKNOWN
> * {{Sarg(10, 20, UNKNOWN AS FALSE)}}: {{x IS NOT NULL AND (x IN (10, 20))}}
> FALSE
> Currently {{class Sarg}} has a field {{boolean containsNull}} which deals
> with the first two cases. Changing {{boolean containsNull}} to {{RexUnknownAs
> unknownAs}} (which has 3 values) will allow us to represent the third. The
> new representation is symmetrical under negation, which de Morgan's law
> suggests is a good thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[
https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256638#comment-17256638
]
Stamatis Zampetakis commented on CALCITE-4188:
--
You opted to model correlated variables as dynamic parameters in the SQL
statement and I think that's a good idea; but from that point onwards I don't
see why we should distinguish them. Possibly we could avoid introducing new
classes such as {{SqlFieldAccessCorrelate}} if we used entirely dynamic params.
I could try to see if it's possible to eliminate SqlFieldAccessCorrelate
without making the code much harder to understand but I was wondering if you
tried that already.
> support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
>
>
> Key: CALCITE-4188
> URL: https://issues.apache.org/jira/browse/CALCITE-4188
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.25.0
>Reporter: JIasen Sheng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
> function
> ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode,
> when implementing,
> [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675]
> will throw null Exception
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256580#comment-17256580
]
Julian Hyde commented on CALCITE-4434:
--
It doesn’t have to be a new PR. In fact it’s better to use the same PR.
Also, as committer you can change the message before you merge someone else’s
change. If that’s all that’s wrong, it’s less effort than asking the
contributor to do it.
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
>
[jira] [Commented] (CALCITE-4188) support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement
[ https://issues.apache.org/jira/browse/CALCITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256379#comment-17256379 ] JIasen Sheng commented on CALCITE-4188: --- Hey [~zabetak] , When assigning values to dynamic parameters in sql, the explicit dynamic parameters are assigned by DataContext, and the values of implicit dynamic parameters are generated by Correlate. Therefore, I think it is necessary to choose different processing logic by distinguishing the types of dynamic parameters. > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > > > Key: CALCITE-4188 > URL: https://issues.apache.org/jira/browse/CALCITE-4188 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.25.0 >Reporter: JIasen Sheng >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > support EnumerableBatchNestedLoopJoin in JdbcToEnumerableConverter implement > function > ENUMERABLE_BATCH_NESTED_LOOP_JOIN_RULE make correlate RexNode, > when implementing, > [https://github.com/apache/calcite/blob/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L675] > will throw null Exception -- This message was sent by Atlassian Jira (v8.3.4#803005)
