[jira] [Created] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
xzh_dz created CALCITE-4783:
---
Summary: Dropped the predicate condition after RelFieldTrimmer
trim the RelNode
Key: CALCITE-4783
URL: https://issues.apache.org/jira/browse/CALCITE-4783
Project: Calcite
Issue Type: Improvement
Reporter: xzh_dz
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
result:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416515#comment-17416515
]
Julian Hyde commented on CALCITE-4783:
--
Please describe the problem.
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> result:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3338) Error with executeBatch and preparedStatement.
[
https://issues.apache.org/jira/browse/CALCITE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416520#comment-17416520
]
Julian Hyde commented on CALCITE-3338:
--
xzh, Do you have a PR for this? Can you please update the subject/description
of the JIRA case. I would like to know what problem you are fixing. (And what
to put in the release notes.)
> Error with executeBatch and preparedStatement.
> --
>
> Key: CALCITE-3338
> URL: https://issues.apache.org/jira/browse/CALCITE-3338
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
> Environment: apache calcite 1.20
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Linux 4.15.0-60-generic #67-Ubuntu
>Reporter: Jacob Roldan
>Priority: Major
> Labels: pull-request-available, test
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> I did a test similar to
> org.apache.calcite.jdbc.CalciteRemoteDriverTest#testInsertBatch but in this
> case using preparedStatement instead of statement:
> {code:java}
> @Test public void testInsertBatchWithPreparedStatement() throws Exception {
> final Connection connection = DriverManager.getConnection(
> "jdbc:avatica:remote:factory="
> + LocalServiceModifiableFactory.class.getName());
> assertThat(connection.getMetaData().supportsBatchUpdates(), is(true));
> assertThat(connection.isClosed(), is(false));
> PreparedStatement pst = connection.prepareStatement("insert into
> \"foo\".\"bar\" values (?,?,?,?,?)");
> pst.setInt(1,1);
> pst.setInt(2,1);
> pst.setString(3,"second");
> pst.setInt(4,1);
> pst.setInt(5,1);
> pst.addBatch();
> pst.addBatch();
> int[] updateCounts = pst.executeBatch();
> assertThat(updateCounts.length, is(2));
> assertThat(updateCounts[0], is(1));
> assertThat(updateCounts[1], is(1));
> ResultSet resultSet = pst.getResultSet();
> assertThat(resultSet, nullValue());
> // Now empty batch
> pst.clearBatch();
> updateCounts = pst.executeBatch();
> assertThat(updateCounts.length, is(0));
> resultSet = pst.getResultSet();
> assertThat(resultSet, nullValue());
> connection.close();
> }
> {code}
> And I got weird exceptions:
> {noformat}
> java.sql.SQLException 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.AvaticaConnection.executeBatchUpdateInternal(AvaticaConnection.java:595)
> at
> org.apache.calcite.avatica.AvaticaPreparedStatement.executeLargeBatch(AvaticaPreparedStatement.java:266)
> at
> org.apache.calcite.avatica.AvaticaPreparedStatement.executeBatch(AvaticaPreparedStatement.java:259)
> at
> org.apache.calcite.jdbc.CalciteRemoteDriverTest.testInsertBatchWithPreparedStatement(CalciteRemoteDriverTest.java:876)
> 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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JU
[jira] [Updated] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4783:
Description:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
trimmed(After RelFieldTrimmer):
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
Compared with RelNode, we can find that there is no predicate condition ename =
'1'.
was:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
result(After RelFieldTrimmer):
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
Compared with RelNode, we can find that there is no predicate condition ename =
'1'.
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed(After RelFieldTrimmer):
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> Compared with RelNode, we can find that there is no predicate condition ename
> = '1'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4783:
Description:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
result(After RelFieldTrimmer):
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
Compared with RelNode, we can find that there is no predicate condition ename =
'1'.
was:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
result:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> result(After RelFieldTrimmer):
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> Compared with RelNode, we can find that there is no predicate condition ename
> = '1'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416527#comment-17416527
]
xzh_dz commented on CALCITE-4783:
-
[~julianhyde]
Thanks, In my project, i always use `RelFieldTrimmer` to trim unused fields.
In this case,there is no predicate condition `ename = '1'` in final
RelNode(trimmed).
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed(After RelFieldTrimmer):
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> Compared with RelNode, we can find that there is no predicate condition ename
> = '1'.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4783:
Description:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
result:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
was:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
trimmed(After RelFieldTrimmer):
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
Compared with RelNode, we can find that there is no predicate condition ename =
'1'.
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> result:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4773) RelDecorrelator's RemoveSingleAggregateRule can produce result with wrong row type
[
https://issues.apache.org/jira/browse/CALCITE-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416539#comment-17416539
]
Ruben Q L commented on CALCITE-4773:
Sure, I have committed a refactoring + some comment improvements.
> RelDecorrelator's RemoveSingleAggregateRule can produce result with wrong row
> type
> --
>
> Key: CALCITE-4773
> URL: https://issues.apache.org/jira/browse/CALCITE-4773
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem can be reproduced with the following test (to be added to
> {{unnest.iq}}):
> {noformat}
> SELECT unnested_outer.val, COUNT(1) AS count_val
> FROM
> (
> SELECT *
> FROM (VALUES (1, array [3, 5]), (2, array [6, 4, 6]))
> AS u(x, y)
> ) AS t, UNNEST(t.y) AS unnested_outer(val)
> WHERE
> (
> SELECT COUNT(unnested_inner.val) > 0
> FROM UNNEST(t.y) AS unnested_inner(val)
> WHERE unnested_inner.val = 4
> )
> GROUP BY unnested_outer.val
> ORDER BY count_val DESC, unnested_outer.val ASC;
> +-+---+
> | VAL | COUNT_VAL |
> +-+---+
> | 6 | 2 |
> | 4 | 1 |
> +-+---+
> (2 rows)
> !ok
> {noformat}
> When the test is executed, it fails with the following error:
> {noformat}
> > java.lang.AssertionError: Cannot add expression of different type to set:
> > set type is RecordType(BOOLEAN NOT NULL $f0) NOT NULL
> > expression type is RecordType(BOOLEAN $f0) NOT NULL
> > set is
> > rel#24436:LogicalAggregate.NONE.[](input=HepRelVertex#24435,group={},agg#0=SINGLE_VALUE($0))
> > expression is LogicalProject($f0=[CAST(>($0, 0)):BOOLEAN])
> > LogicalAggregate(group=[{}], agg#0=[COUNT()])
> > LogicalFilter(condition=[=($0, 4)])
> > LogicalProject(VAL=[$0])
> > Uncollect
> > LogicalProject(Y=[$cor1.Y])
> > LogicalValues(tuples=[[{ 0 }]])
> 249a254,325
> > at
> > org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:391)
> > at
> > org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:60)
> > at
> > org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:269)
> > at
> > org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:284)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator$RemoveSingleAggregateRule.onMatch(RelDecorrelator.java:1923)
> > at
> > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> > at
> > org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> ...
> {noformat}
> The root cause seems to be in this piece of code inside {{RelDecorrelator}}'s
> {{RemoveSingleAggregateRule#onMatch}}:
> {code:java}
> // singleAggRel produces a nullable type, so create the new
> // projection that casts proj expr to a nullable type.
> final RelBuilder relBuilder = call.builder();
> final RelDataType type =
> relBuilder.getTypeFactory()
> .createTypeWithNullability(projExprs.get(0).getType(), true);
> final RexNode cast = relBuilder.getRexBuilder().makeCast(type,
> projExprs.get(0));
> relBuilder.push(aggregate).project(cast);
> call.transformTo(relBuilder.build());
> {code}
> Note that the comment assumes that _"singleAggRel produces a nullable type"_,
> but in this particular case, it seems to produce a non-nullable type, so
> probably this piece of code needs to be adapted.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4337) Supports PARTITION BY clause for table function table argument
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4337:
Labels: pull-request-available (was: )
> Supports PARTITION BY clause for table function table argument
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4784) Ensure Correlate#requiredColumns is subset of columns in left relation
Stamatis Zampetakis created CALCITE-4784:
Summary: Ensure Correlate#requiredColumns is subset of columns in
left relation
Key: CALCITE-4784
URL: https://issues.apache.org/jira/browse/CALCITE-4784
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis
Fix For: 1.28.0
The {{Correlate}}
[expression|https://github.com/apache/calcite/blob/f3baf348598fcc6bc4f97a0abee3f99309e5bf76/core/src/main/java/org/apache/calcite/rel/core/Correlate.java]
has among others a field ({{requiredColumns}} for representing the set of
columns that are used by the correlation.
{code:java}
public abstract class Correlate extends BiRel {
protected final CorrelationId correlationId;
protected final ImmutableBitSet requiredColumns;
protected final JoinRelType joinType;
/**
* Returns the required columns in left relation required for the correlation
* in the right.
*
* @return columns in left relation required for the correlation in the right
*/
public ImmutableBitSet getRequiredColumns() {
return requiredColumns;
}
{code}
As the javadoc indicates (implicitly) these columns must be a subset of the
columns of the left relation. This is currently not enforced when creating a
correlation which can lead to invalid plans and runtime failures which are hard
to investigate.
I propose to introduce an additional check inside {{Correlate#isValid}} method
for enforcing that required columns are valid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4784) Ensure Correlate#requiredColumns is subset of columns in left relation
[
https://issues.apache.org/jira/browse/CALCITE-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4784:
Labels: pull-request-available (was: )
> Ensure Correlate#requiredColumns is subset of columns in left relation
> --
>
> Key: CALCITE-4784
> URL: https://issues.apache.org/jira/browse/CALCITE-4784
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{Correlate}}
> [expression|https://github.com/apache/calcite/blob/f3baf348598fcc6bc4f97a0abee3f99309e5bf76/core/src/main/java/org/apache/calcite/rel/core/Correlate.java]
> has among others a field ({{requiredColumns}} for representing the set of
> columns that are used by the correlation.
> {code:java}
> public abstract class Correlate extends BiRel {
> protected final CorrelationId correlationId;
> protected final ImmutableBitSet requiredColumns;
> protected final JoinRelType joinType;
> /**
>* Returns the required columns in left relation required for the
> correlation
>* in the right.
>*
>* @return columns in left relation required for the correlation in the
> right
>*/
> public ImmutableBitSet getRequiredColumns() {
> return requiredColumns;
> }
> {code}
> As the javadoc indicates (implicitly) these columns must be a subset of the
> columns of the left relation. This is currently not enforced when creating a
> correlation which can lead to invalid plans and runtime failures which are
> hard to investigate.
> I propose to introduce an additional check inside {{Correlate#isValid}}
> method for enforcing that required columns are valid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4784) Ensure Correlate#requiredColumns is subset of columns in left relation
[
https://issues.apache.org/jira/browse/CALCITE-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416759#comment-17416759
]
Julian Hyde commented on CALCITE-4784:
--
If it’s a quick check, consider making it a precondition in the constructor.
Invariants are good.
> Ensure Correlate#requiredColumns is subset of columns in left relation
> --
>
> Key: CALCITE-4784
> URL: https://issues.apache.org/jira/browse/CALCITE-4784
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{Correlate}}
> [expression|https://github.com/apache/calcite/blob/f3baf348598fcc6bc4f97a0abee3f99309e5bf76/core/src/main/java/org/apache/calcite/rel/core/Correlate.java]
> has among others a field ({{requiredColumns}} for representing the set of
> columns that are used by the correlation.
> {code:java}
> public abstract class Correlate extends BiRel {
> protected final CorrelationId correlationId;
> protected final ImmutableBitSet requiredColumns;
> protected final JoinRelType joinType;
> /**
>* Returns the required columns in left relation required for the
> correlation
>* in the right.
>*
>* @return columns in left relation required for the correlation in the
> right
>*/
> public ImmutableBitSet getRequiredColumns() {
> return requiredColumns;
> }
> {code}
> As the javadoc indicates (implicitly) these columns must be a subset of the
> columns of the left relation. This is currently not enforced when creating a
> correlation which can lead to invalid plans and runtime failures which are
> hard to investigate.
> I propose to introduce an additional check inside {{Correlate#isValid}}
> method for enforcing that required columns are valid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4783) Dropped the predicate condition after RelFieldTrimmer trim the RelNode
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416848#comment-17416848
]
Julian Hyde commented on CALCITE-4783:
--
Can you modify the subject/description so that someone reading the release
notes or reading this case would know whether they are hitting this bug.
> Dropped the predicate condition after RelFieldTrimmer trim the RelNode
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> result:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
Viliam Durina created CALCITE-4785:
--
Summary: The parser allows multiple ON ERROR or ON EMPTY clauses
for JSON_QUERY and JSON_VALUE
Key: CALCITE-4785
URL: https://issues.apache.org/jira/browse/CALCITE-4785
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.27.0
Reporter: Viliam Durina
The following expression parses succesfully:
{{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
The 2nd ON ERROR clause overrides the 1st one and it returns {{2}}. Instead, an
error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viliam Durina updated CALCITE-4785:
---
Description:
The following expression parses succesfully:
{{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
The 2nd ON ERROR clause overrides the 1st one and the expression returns {{2}}.
Instead, an error should be thrown.
was:
The following expression parses succesfully:
{{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
The 2nd ON ERROR clause overrides the 1st one and it returns {{2}}. Instead, an
error should be thrown.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
>
> The following expression parses succesfully:
> {{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416876#comment-17416876
]
Julian Hyde commented on CALCITE-4785:
--
Can you confirm that this is an error per the standard?
And even if it should be an error, it may be better to throw an error in the
validator than in the parser. I believe that parsers should be fairly stupid.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
>
> The following expression parses succesfully:
> {{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4767: Labels: pull-request-available (was: ) > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416888#comment-17416888 ] Julian Hyde commented on CALCITE-4767: -- [~jackscott], No, just a branch. It's confusing if we both have PRs. > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416894#comment-17416894
]
Viliam Durina commented on CALCITE-4785:
Unfortunately I don't have access to the standard. Oracle reports it as error.
And it also makes sense because SQL is a declarative language and expressions
coming later don't override expressions coming before them.
Validator/parser reporting the error - doesn't matter to the end user much.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
>
> The following expression parses succesfully:
> {{JSON_VALUE('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viliam Durina updated CALCITE-4785:
---
Description:
The following expression parses succesfully:
{{JSON_VALUE('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
The 2nd ON ERROR clause overrides the 1st one and the expression returns {{2}}.
Instead, an error should be thrown.
was:
The following expression parses succesfully:
{{JSON_QUERY('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
The 2nd ON ERROR clause overrides the 1st one and the expression returns {{2}}.
Instead, an error should be thrown.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
>
> The following expression parses succesfully:
> {{JSON_VALUE('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416903#comment-17416903 ] Jack Scott commented on CALCITE-4767: - [https://github.com/apache/calcite/pull/2527] PR for SQL generation of escaped backticks. > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4742) Implement NOT EQUALS in SOME sub-query
[
https://issues.apache.org/jira/browse/CALCITE-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-4742.
--
Resolution: Fixed
Merged as
[053d9b7e|https://github.com/apache/calcite/commit/053d9b7e25ded230e8449b51d26a6d3cacac8fbe];
thanks for the PR, [~nobigo]!
> Implement NOT EQUALS in SOME sub-query
> --
>
> Key: CALCITE-4742
> URL: https://issues.apache.org/jira/browse/CALCITE-4742
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ivan Daschinsky
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When executing
> {code}
> select * from "scott".emp where empno <> any (select 10);
> {code}
> with assertions, got assertion error
> {code}
> ---
> > java.lang.AssertionError
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:170)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.matchFilter(SubQueryRemoveRule.java:637)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.access$100(SubQueryRemoveRule.java:71)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$3(SubQueryRemoveRule.java:701)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:82)
> > at
> > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:282)
> > at
> > org.apache.calcite.plan.hep.HepInstruction$RuleCollection.execute(HepInstruction.java:77)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> > at org.apache.calcite.tools.Programs.lambda$of$0(Programs.java:176)
> > at
> > org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:335)
> > at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:172)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:306)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> {code}
> This query cannot be rewritten as IN query, so it goes to
> {{SubQueryRemoveRule.rewriteSome}}. Current logic in this method doesn't work
> on this case and produce wrong plan.
> This query should be rewritten to something like this:
> {code}
> select distinct(e.*) from "scott".emp as e inner join (select 10 as empno)
> as q on e.empno <> q.empno;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4742) Implement "<> SOME" sub-query
[
https://issues.apache.org/jira/browse/CALCITE-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4742:
-
Summary: Implement "<> SOME" sub-query (was: Implement "SOME <>" sub-query)
> Implement "<> SOME" sub-query
> -
>
> Key: CALCITE-4742
> URL: https://issues.apache.org/jira/browse/CALCITE-4742
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ivan Daschinsky
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When executing
> {code}
> select * from "scott".emp where empno <> any (select 10);
> {code}
> with assertions, got assertion error
> {code}
> ---
> > java.lang.AssertionError
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:170)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.matchFilter(SubQueryRemoveRule.java:637)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.access$100(SubQueryRemoveRule.java:71)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$3(SubQueryRemoveRule.java:701)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:82)
> > at
> > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:282)
> > at
> > org.apache.calcite.plan.hep.HepInstruction$RuleCollection.execute(HepInstruction.java:77)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> > at org.apache.calcite.tools.Programs.lambda$of$0(Programs.java:176)
> > at
> > org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:335)
> > at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:172)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:306)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> {code}
> This query cannot be rewritten as IN query, so it goes to
> {{SubQueryRemoveRule.rewriteSome}}. Current logic in this method doesn't work
> on this case and produce wrong plan.
> This query should be rewritten to something like this:
> {code}
> select distinct(e.*) from "scott".emp as e inner join (select 10 as empno)
> as q on e.empno <> q.empno;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4742) Implement "SOME <>" sub-query
[
https://issues.apache.org/jira/browse/CALCITE-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4742:
-
Summary: Implement "SOME <>" sub-query (was: Implement NOT EQUALS in SOME
sub-query)
> Implement "SOME <>" sub-query
> -
>
> Key: CALCITE-4742
> URL: https://issues.apache.org/jira/browse/CALCITE-4742
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Ivan Daschinsky
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When executing
> {code}
> select * from "scott".emp where empno <> any (select 10);
> {code}
> with assertions, got assertion error
> {code}
> ---
> > java.lang.AssertionError
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:170)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.matchFilter(SubQueryRemoveRule.java:637)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.access$100(SubQueryRemoveRule.java:71)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$3(SubQueryRemoveRule.java:701)
> > at
> > org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:82)
> > at
> > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:282)
> > at
> > org.apache.calcite.plan.hep.HepInstruction$RuleCollection.execute(HepInstruction.java:77)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> > at org.apache.calcite.tools.Programs.lambda$of$0(Programs.java:176)
> > at
> > org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:335)
> > at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:172)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:306)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:215)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> {code}
> This query cannot be rewritten as IN query, so it goes to
> {{SubQueryRemoveRule.rewriteSome}}. Current logic in this method doesn't work
> on this case and produce wrong plan.
> This query should be rewritten to something like this:
> {code}
> select distinct(e.*) from "scott".emp as e inner join (select 10 as empno)
> as q on e.empno <> q.empno;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416942#comment-17416942 ] Julian Hyde commented on CALCITE-4767: -- I merged PR 153 to Avatica as [0574db|https://github.com/apache/calcite-avatica/commit/0574db65ad08e8682277885a86cf3fbba76a1d21]; will be in Avatica 1.19. Thanks for the PR, [~jackscott]! > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan resolved CALCITE-4774.
Fix Version/s: 1.28.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/60457b28c890f12cc811528bd4f3b098bc3d00f7,
thanks for the PR, [~xzh_dz].
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416958#comment-17416958
]
duan xiong commented on CALCITE-4774:
-
[~hyuan] As a comment on _PR_ before_,_ This PR includes two tests are one and
the same. Please check that. Thanks.
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416958#comment-17416958
]
duan xiong edited comment on CALCITE-4774 at 9/17/21, 10:50 PM:
[~hyuan] As a comment on _PR_ before. This PR includes two tests are one and
the same. Please check that. Thanks.
was (Author: nobigo):
[~hyuan] As a comment on _PR_ before_,_ This PR includes two tests are one and
the same. Please check that. Thanks.
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4767: - Fix Version/s: 1.28.0 > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Fix For: 1.28.0 > > Time Spent: 50m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4767) BigQuerySqlDialect uses the wrong identifier escape character
[ https://issues.apache.org/jira/browse/CALCITE-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4767: - Component/s: jdbc-adapter > BigQuerySqlDialect uses the wrong identifier escape character > - > > Key: CALCITE-4767 > URL: https://issues.apache.org/jira/browse/CALCITE-4767 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Jack Scott >Assignee: Jack Scott >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > > BigQuery Standard SQL uses backslashes to escape backticks in identifiers, > e.g. `foo\`bar`, whereas the "identifierEscapedQuote" in Calcite's > BigQuerySqlDialect is a double backtick, e.g. `foo``bar`, which does not work > in BQ Standard SQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4686) SubQueryRemoveRule.matchJoin should correctly rewrite all sub-queries
[
https://issues.apache.org/jira/browse/CALCITE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416966#comment-17416966
]
James Starr commented on CALCITE-4686:
--
[~zabetak], Could we move forward with merging this?
> SubQueryRemoveRule.matchJoin should correctly rewrite all sub-queries
> -
>
> Key: CALCITE-4686
> URL: https://issues.apache.org/jira/browse/CALCITE-4686
> Project: Calcite
> Issue Type: Improvement
>Reporter: James Starr
>Assignee: James Starr
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> SubQueryRemoveRule.matchJoin only rewrites the first subquery in an ON
> condition each call. It should rewrite all of them down right side of the
> join in single call. Furthermore, the filter generated is not shifted
> correctly for the scope that it is being applied to.
> RelOptRulesTest.testExpandJoinIn, which currently disabled, throw an
> exception when run because filter is shifted to be applied to in the context
> of the right side but it applied on top of the join. Which can be observed
> by commenting out the litmus check.
> {code:java}
> @Test void testExpandJoinIn() {
> final String sql = "select empno\n"
> + "from sales.emp left join sales.dept\n"
> + "on emp.deptno in (select deptno from sales.emp where empno < 20)";
> checkSubQuery(sql).check();
> }
> {code}
> {noformat}
> RexInputRef index 7 out of range 0..2
> java.lang.AssertionError: RexInputRef index 7 out of range 0..2
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Join.isValid(Join.java:176)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4261)
> at org.apache.calcite.rel.BiRel.childrenAccept(BiRel.java:46)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.RelVisitor.go(RelVisitor.java:63)
> at
> org.apache.calcite.test.SqlToRelTestBase.assertValid(SqlToRelTestBase.java:154)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:163)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:109)
> at
> org.apache.calcite.test.RelOptTestBase.access$100(RelOptTestBase.java:66)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:340)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:316)
> at
> org.apache.calcite.test.RelOptRulesTest.testExpandJoinIn(RelOptRulesTest.java:5702)
> 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)
>
[jira] [Commented] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416969#comment-17416969
]
Haisheng Yuan commented on CALCITE-4774:
Hi [~nobigo], I checked the code again, they are not the same.
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4774) When predicate conditions are equivalent, materialized view recognition fails.
[
https://issues.apache.org/jira/browse/CALCITE-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416976#comment-17416976
]
duan xiong commented on CALCITE-4774:
-
[~hyuan]. I am sorry for my mistake．+1
> When predicate conditions are equivalent, materialized view recognition fails.
> --
>
> Key: CALCITE-4774
> URL: https://issues.apache.org/jira/browse/CALCITE-4774
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testRexCondition() {
> final String mv = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100 and \"deptno\" > 50\n"
> + "group by \"name\"";
> final String query = ""
> + "select \"name\"\n"
> + "from \"emps\"\n"
> + "where \"deptno\" > 100"
> + "group by \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4737) Add Volcano visualizer for debugging
[ https://issues.apache.org/jira/browse/CALCITE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417002#comment-17417002 ] Botong Huang commented on CALCITE-4737: --- [~zuozhiw] and [~thomas.rebele], any updates? Please let me know if there's anything I can help. Thanks! > Add Volcano visualizer for debugging > > > Key: CALCITE-4737 > URL: https://issues.apache.org/jira/browse/CALCITE-4737 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 3h 50m > Remaining Estimate: 0h > > Add Volcano visualizer for debugging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
