[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[ https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367225#comment-15367225 ] Jark Wu commented on CALCITE-1297: -- [~julianhyde], I'm glad to work on it. And I have updated the PR [1] according to my understanding. [1]: https://github.com/apache/calcite/pull/251 > RelBuilder does not translate identity projects even if they rename fields > -- > > Key: CALCITE-1297 > URL: https://issues.apache.org/jira/browse/CALCITE-1297 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.8.0 >Reporter: Jark Wu >Assignee: Julian Hyde > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1310) SqlBetweenOperator should defer SqlOperandTypeInference for PreparedStatement
[
https://issues.apache.org/jira/browse/CALCITE-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367207#comment-15367207
]
Julian Hyde commented on CALCITE-1310:
--
I was able to reproduce it by adding a few lines to
{{SqlValidatorTest.testBind}}:
{code}
sql("select * from emp where deptno between ? and ?").ok();
sql("select * from emp where ? between deptno and ?").ok();
sql("select * from emp where ? between ? and deptno").ok();
{code}
The fix is probably to give {{SqlBetweenOperator}} a
{{SqlOperandTypeInference}} like the one in {{SqlBinaryOperator}} (used for
{{<}} for example), where the type of unknown operands is deduced to be the
same as the type of known operands.
> SqlBetweenOperator should defer SqlOperandTypeInference for PreparedStatement
> -
>
> Key: CALCITE-1310
> URL: https://issues.apache.org/jira/browse/CALCITE-1310
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.7.0, 1.6.0, 1.8.0
>Reporter: Yiming Liu
>Assignee: Julian Hyde
>Priority: Minor
>
> The following PreparedStatement does not work in SQL validation phase.
> {code}
> final String sql = "select count( * ) from kylin_sales where
> LSTG_SITE_ID between ? and ?";
> try (PreparedStatement stmt = conn.prepareStatement(sql)) {
> stmt.setInt(1, 0);
> stmt.setInt(2, 5);
> try (ResultSet rs = stmt.executeQuery()) {
> printResultSet(rs);
> }
> }
> {code}
> It seems the SqlBetweenOperator does not infer the operand type when parsing.
> So in the SQL validation phase, the NULL operandTypeInference will throw out
> exceptions. At the other side, The SqlInOperator will defer the parameter
> type when parsing.
> Following is the detail exception log
> {noformat}
> Caused by: org.apache.calcite.runtime.CalciteContextException: At line 1,
> column 61: Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1565)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1648)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:3374)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:3366)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:2961)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:86)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:848)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:834)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:207)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:808)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:522)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:534)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:226)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:196)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:721)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:588)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:558)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:194)
> ... 78 more
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal
[jira] [Updated] (CALCITE-1310) SqlBetweenOperator should defer SqlOperandTypeInference for PreparedStatement
[
https://issues.apache.org/jira/browse/CALCITE-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1310:
-
Description:
The following PreparedStatement does not work in SQL validation phase.
{code}
final String sql = "select count( * ) from kylin_sales where
LSTG_SITE_ID between ? and ?";
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.setInt(1, 0);
stmt.setInt(2, 5);
try (ResultSet rs = stmt.executeQuery()) {
printResultSet(rs);
}
}
{code}
It seems the SqlBetweenOperator does not infer the operand type when parsing.
So in the SQL validation phase, the NULL operandTypeInference will throw out
exceptions. At the other side, The SqlInOperator will defer the parameter type
when parsing.
Following is the detail exception log
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 1,
column 61: Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1565)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1648)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:3374)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:3366)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:2961)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:86)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:848)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:834)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:207)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:808)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:522)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:534)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:226)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:196)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:721)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:588)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:558)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:194)
... 78 more
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal use
of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:514)
... 101 more
{noformat}
was:
The following PreparedStatement does not work in SQL validation phase.
final String sql = "select count(*) from kylin_sales where LSTG_SITE_ID
between ? and ?";
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.setInt(1, 0);
stmt.setInt(2, 5);
try (ResultSet rs = stmt.executeQuery()) {
printResultSet(rs);
}
}
It seems the SqlBetweenOperator does not infer the operand type when parsing.
So in the SQL validation
[jira] [Created] (CALCITE-1310) SqlBetweenOperator should defer SqlOperandTypeInference for PreparedStatement
Yiming Liu created CALCITE-1310:
---
Summary: SqlBetweenOperator should defer SqlOperandTypeInference
for PreparedStatement
Key: CALCITE-1310
URL: https://issues.apache.org/jira/browse/CALCITE-1310
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.6.0, 1.7.0, 1.8.0
Reporter: Yiming Liu
Assignee: Julian Hyde
Priority: Minor
The following PreparedStatement does not work in SQL validation phase.
final String sql = "select count(*) from kylin_sales where LSTG_SITE_ID
between ? and ?";
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.setInt(1, 0);
stmt.setInt(2, 5);
try (ResultSet rs = stmt.executeQuery()) {
printResultSet(rs);
}
}
It seems the SqlBetweenOperator does not infer the operand type when parsing.
So in the SQL validation phase, the NULL operandTypeInference will throw out
exceptions. At the other side, The SqlInOperator will defer the parameter type
when parsing.
Following is the detail exception log
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 1,
column 61: Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1565)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1648)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:3374)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:3366)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:2961)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:86)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:848)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:834)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:207)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:808)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:522)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:534)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:226)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:196)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:721)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:588)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:558)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:194)
... 78 more
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal use
of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:514)
... 101 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1301) Add cancel flag to AvaticaResultSet
[
https://issues.apache.org/jira/browse/CALCITE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367076#comment-15367076
]
Julian Hyde commented on CALCITE-1301:
--
The fix to CALCITE-30 is now checked in. On
https://github.com/julianhyde/calcite/tree/1270-avatica-1.9 I have one commit
that fixes this issue in Avatica, and another that makes the corresponding
change to Calcite. We need to merge that branch to master before avatica-1.9.
> Add cancel flag to AvaticaResultSet
> ---
>
> Key: CALCITE-1301
> URL: https://issues.apache.org/jira/browse/CALCITE-1301
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: avatica
> Fix For: avatica-1.9.0
>
>
> Add cancel flag to AvaticaResultSet. The flag was added to CalciteResultSet
> as part of CALCITE-1227, but would be useful in the Avatica base class.
> It is currently of type {{CancelFlag}} but maybe it should become
> {{AtomicBoolean}}.
> To complete implementation of java.sql.Statement#cancel we would need a
> Cancel command; that is out of scope of this case, and would be covered by
> CALCITE-520.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-30) Implement Statement.cancel method
[ https://issues.apache.org/jira/browse/CALCITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-30: --- Summary: Implement Statement.cancel method (was: Statement#cancel unimplemented) > Implement Statement.cancel method > - > > Key: CALCITE-30 > URL: https://issues.apache.org/jira/browse/CALCITE-30 > Project: Calcite > Issue Type: Bug >Reporter: GitHub Import > Labels: github-import, newbie > Fix For: 1.9.0 > > > would be good to have the ability to push a cancel() call down to the > underlying framework. > this would allow for a Cascading Flow to be stopped mid-flight. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/30 > Created by: [cwensel|https://github.com/cwensel] > Labels: > Created at: Sun Mar 17 03:06:57 CET 2013 > State: open -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1227) Add streaming CSV table
[
https://issues.apache.org/jira/browse/CALCITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1227.
--
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/65c1cec2.
> Add streaming CSV table
> ---
>
> Key: CALCITE-1227
> URL: https://issues.apache.org/jira/browse/CALCITE-1227
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.9.0
>
>
> Add a variant of CsvTable that can be streamed. It would serve as an example
> of how to write stream adapters.
> It would be like the CSV adapter, but watches a file and reports records
> added to the end of the file (like the tail command).
> You’d have to change {{CsvTable}} to implement {{StreamableTable}}, and
> implement the {{Table stream()}} method to return a variant of the table that
> is in “follow” mode.
> It would probably be implemented by a variant of CsvEnumerator, but it is
> getting its input in bursts, as the file is appended to.
> You would still be able to use this adapter to read historical data from the
> CSV file. Appending records to the file would make a nice demo.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1288) Avoid doing the same join twice if count(distinct) exists
[
https://issues.apache.org/jira/browse/CALCITE-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366895#comment-15366895
]
Julian Hyde commented on CALCITE-1288:
--
[~gparai], Are you planning to fix review comments in the PR? Please also
squash and rebase.
> Avoid doing the same join twice if count(distinct) exists
> -
>
> Key: CALCITE-1288
> URL: https://issues.apache.org/jira/browse/CALCITE-1288
> Project: Calcite
> Issue Type: Improvement
>Reporter: Gautam Kumar Parai
>Assignee: Gautam Kumar Parai
>
> When the query has one distinct aggregate and one or more non-distinct
> aggregates, the join instance need not produce the join-based plan. We can
> generate multi-phase aggregates. Another approach would be to use grouping
> sets. However, this transformation will be useful when systems don't support
> grouping sets and instead rely on the join-based plans (see the plan below)
> {code}
> select emp.empno, count(*), avg(distinct dept.deptno)
> from sales.emp emp inner join sales.dept dept
> on emp.deptno = dept.deptno
> group by emp.empno
> LogicalProject(EMPNO=[$0], EXPR$1=[$1], EXPR$2=[$3])
> LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $2)], joinType=[inner])
> LogicalAggregate(group=[{0}], EXPR$1=[COUNT()])
> LogicalProject(EMPNO=[$0], DEPTNO0=[$9])
> LogicalJoin(condition=[=($7, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalAggregate(group=[{0}], EXPR$2=[AVG($1)])
> LogicalAggregate(group=[{0, 1}])
> LogicalProject(EMPNO=[$0], DEPTNO0=[$9])
> LogicalJoin(condition=[=($7, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> The more efficient form should look like
> {code}
> select emp.empno, count(*), avg(distinct dept.deptno)
> from sales.emp emp inner join sales.dept dept
> on emp.deptno = dept.deptno
> group by emp.empno
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($2)], EXPR$2=[AVG($1)])
> LogicalAggregate(group=[{0, 1}], EXPR$1=[COUNT()])
> LogicalProject(EMPNO=[$0], DEPTNO0=[$9])
> LogicalJoin(condition=[=($7, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1308) Primary Keys for Phoenix table not recognized in sqlline.
Josh Elser created CALCITE-1308: --- Summary: Primary Keys for Phoenix table not recognized in sqlline. Key: CALCITE-1308 URL: https://issues.apache.org/jira/browse/CALCITE-1308 Project: Calcite Issue Type: Bug Reporter: Josh Elser Assignee: Josh Elser Priority: Minor Fix For: avatica-1.9.0 Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are (part of the) primary key. Running a debugger over it quickly, showed that no keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1295) ReduceExpressionRule should not reduce AS operator
[
https://issues.apache.org/jira/browse/CALCITE-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1295.
--
Resolution: Invalid
I only just noticed that you are calling {{LogicalProject.create}}. It's
reasonable that {{RelBuilder.project}} should strip {{AS}} calls out of
expressions, but I don't think {{LogicalProject.create}} should do that.
There's no good reason to have AS calls in RexNode trees once the SQL has been
translated and column names have been determined.
In summary, I don't think this is a bug in {{ReduceExpressionRule}}, it's a bug
in your code. If you want {{AS}} to be stripped out, call
{{RelBuilder.project}} rather than {{LogicalProject.create}}.
Closing as invalid.
> ReduceExpressionRule should not reduce AS operator
> --
>
> Key: CALCITE-1295
> URL: https://issues.apache.org/jira/browse/CALCITE-1295
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Jark Wu
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.8.0, 1.9.0
>
>
> In extremely rare cases, if we build relation tree ourselves through
> RelBuilder.
> {code:java}
> relBuilder.push(
> LogicalProject.create(relBuilder.peek(),
> Lists.newArrayList(relBuilder.alias(relBuilder.literal(true),
> "_c0")),
> Lists.newArrayList("_c0")))
> {code}
> Then we may have AS(true, $1) in the expressions, and AS(true, $1) can
> satisfy ReduceExpressionRule, but AS call do not exist in
> RexImpTable.INSTANCE, so it throws this :
> {code:java}
> java.lang.RuntimeException: cannot translate call AS($t0, $t1)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:533)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:507)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:219)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:472)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:219)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:214)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateList(RexToLixTranslator.java:700)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateProjects(RexToLixTranslator.java:189)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:80)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:59)
> at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:118)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:544)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:455)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:438)
> {{code}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1297) RelBuilder does not translate identity projects even if they rename fields
[ https://issues.apache.org/jira/browse/CALCITE-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366648#comment-15366648 ] Julian Hyde commented on CALCITE-1297: -- [~jark], Are you interested in developing a patch for this? > RelBuilder does not translate identity projects even if they rename fields > -- > > Key: CALCITE-1297 > URL: https://issues.apache.org/jira/browse/CALCITE-1297 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.8.0 >Reporter: Jark Wu >Assignee: Julian Hyde > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
