[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[ https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859781#comment-16859781 ] Julian Hyde commented on CALCITE-3005: -- Fixed in [90a431691|https://github.com/apache/calcite/commit/90a431691]. > Implement string functions: LEFT, RIGHT > --- > > Key: CALCITE-3005 > URL: https://issues.apache.org/jira/browse/CALCITE-3005 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Some string functions including LEFT, RIGHT are not implemented now. It would > be great if these functions can be implemented. > [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left] > Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. > [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right] > Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2744) RelDecorrelator use wrong output map for LogicalAggregate decorrelate
[ https://issues.apache.org/jira/browse/CALCITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2744. -- Resolution: Fixed Sorry for the confusion, [~danny0405]; as it was a simple fix I rolled into the fixup for CALCITE-3005, and it had already passed all of my tests before I saw your PR. Fixed in [90a431691|https://github.com/apache/calcite/commit/90a431691]. > RelDecorrelator use wrong output map for LogicalAggregate decorrelate > - > > Key: CALCITE-2744 > URL: https://issues.apache.org/jira/browse/CALCITE-2744 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.20.0 >Reporter: Wei Zhong >Assignee: Danny Chan >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > when running the following test in org.apache.calcite.test.RelOptRulesTest, > we will get a RuntimeException: > {code:java} > @Test public void testDecorrelateWith2ParamsAgg() { > final HepProgram preProgram = > HepProgram.builder() > .addRuleInstance(FilterProjectTransposeRule.INSTANCE) > .addRuleInstance(FilterJoinRule.FILTER_ON_JOIN) > .addRuleInstance(ProjectMergeRule.INSTANCE) > .build(); > final HepProgram program = > HepProgram.builder() > .addRuleInstance(SemiJoinRule.PROJECT) > .build(); > final String sql = "select * from dept where exists (\n" > + "select UDF_AVG(sal, sal + 1) from sales.emp\n" > + "where emp.deptno = dept.deptno\n" > + "and emp.sal > 100)"; > Sql sqlTest = sql(sql) > .withDecorrelation(true) > .withTrim(true) > .withPre(preProgram) > .with(program); > sqlTest.check(); > } > {code} > UDF_AVG code in MockSqlOperatorTable: > {code:java} > public static void addRamp(MockSqlOperatorTable opTab) { > // Don't use anonymous inner classes. They can't be instantiated > // using reflection when we are deserializing from JSON. > opTab.addOperator(new RampFunction()); > opTab.addOperator(new DedupFunction()); > opTab.addOperator(UDF_AVG); > } > public static final SqlFunction UDF_AVG = new SqlAggFunction( > "UDF_AVG", > null, > SqlKind.OTHER_FUNCTION, > ReturnTypes.AVG_AGG_FUNCTION, > null, > OperandTypes.family(SqlTypeFamily.NUMERIC, SqlTypeFamily.NUMERIC), > SqlFunctionCategory.NUMERIC, > false, > false, > Optionality.FORBIDDEN) { > @Override public boolean isDeterministic() { > return false; > } > }; > {code} > The RuntimeExcpetion detail: > {code:java} > java.lang.RuntimeException: While invoking method 'public > org.apache.calcite.sql2rel.RelDecorrelator$Frame > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(org.apache.calcite.rel.logical.LogicalProject)' > at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527) > at > org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:613) > at > org.apache.calcite.sql2rel.RelDecorrelator.decorrelate(RelDecorrelator.java:254) > at > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:214) > at > org.apache.calcite.sql2rel.SqlToRelConverter.decorrelateQuery(SqlToRelConverter.java:3037) > at > org.apache.calcite.sql2rel.SqlToRelConverter.decorrelate(SqlToRelConverter.java:481) > at > org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:615) > at > org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:177) > at org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334) > at org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317) > at > org.apache.calcite.test.RelOptRulesTest.testDecorrelateWith2ParamsAgg(RelOptRulesTest.java:4286) > 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.
[jira] [Assigned] (CALCITE-2510) Add CHR built-in function (Oracle only)
[ https://issues.apache.org/jira/browse/CALCITE-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chunwei Lei reassigned CALCITE-2510: Assignee: Chunwei Lei > Add CHR built-in function (Oracle only) > --- > > Key: CALCITE-2510 > URL: https://issues.apache.org/jira/browse/CALCITE-2510 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Sergey Tsvetkov >Assignee: Chunwei Lei >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Adding CHR() function support, available in Oracle & PostgreSql > [https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions019.htm] > [https://www.postgresql.org/docs/9.4/static/functions-string.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2744) RelDecorrelator use wrong output map for LogicalAggregate decorrelate
[ https://issues.apache.org/jira/browse/CALCITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859828#comment-16859828 ] Danny Chan commented on CALCITE-2744: - Thanks [~julianhyde], i still apply the fix because i think the original name "MY_AVG" name is misleading. Fixed in [340e21a6a|https://github.com/apache/calcite/commit/340e21a6a93e0766acf3fa292c4ecd86d5f5f8ef] ! > RelDecorrelator use wrong output map for LogicalAggregate decorrelate > - > > Key: CALCITE-2744 > URL: https://issues.apache.org/jira/browse/CALCITE-2744 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.20.0 >Reporter: Wei Zhong >Assignee: Danny Chan >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 3h > Remaining Estimate: 0h > > when running the following test in org.apache.calcite.test.RelOptRulesTest, > we will get a RuntimeException: > {code:java} > @Test public void testDecorrelateWith2ParamsAgg() { > final HepProgram preProgram = > HepProgram.builder() > .addRuleInstance(FilterProjectTransposeRule.INSTANCE) > .addRuleInstance(FilterJoinRule.FILTER_ON_JOIN) > .addRuleInstance(ProjectMergeRule.INSTANCE) > .build(); > final HepProgram program = > HepProgram.builder() > .addRuleInstance(SemiJoinRule.PROJECT) > .build(); > final String sql = "select * from dept where exists (\n" > + "select UDF_AVG(sal, sal + 1) from sales.emp\n" > + "where emp.deptno = dept.deptno\n" > + "and emp.sal > 100)"; > Sql sqlTest = sql(sql) > .withDecorrelation(true) > .withTrim(true) > .withPre(preProgram) > .with(program); > sqlTest.check(); > } > {code} > UDF_AVG code in MockSqlOperatorTable: > {code:java} > public static void addRamp(MockSqlOperatorTable opTab) { > // Don't use anonymous inner classes. They can't be instantiated > // using reflection when we are deserializing from JSON. > opTab.addOperator(new RampFunction()); > opTab.addOperator(new DedupFunction()); > opTab.addOperator(UDF_AVG); > } > public static final SqlFunction UDF_AVG = new SqlAggFunction( > "UDF_AVG", > null, > SqlKind.OTHER_FUNCTION, > ReturnTypes.AVG_AGG_FUNCTION, > null, > OperandTypes.family(SqlTypeFamily.NUMERIC, SqlTypeFamily.NUMERIC), > SqlFunctionCategory.NUMERIC, > false, > false, > Optionality.FORBIDDEN) { > @Override public boolean isDeterministic() { > return false; > } > }; > {code} > The RuntimeExcpetion detail: > {code:java} > java.lang.RuntimeException: While invoking method 'public > org.apache.calcite.sql2rel.RelDecorrelator$Frame > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(org.apache.calcite.rel.logical.LogicalProject)' > at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527) > at > org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:613) > at > org.apache.calcite.sql2rel.RelDecorrelator.decorrelate(RelDecorrelator.java:254) > at > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:214) > at > org.apache.calcite.sql2rel.SqlToRelConverter.decorrelateQuery(SqlToRelConverter.java:3037) > at > org.apache.calcite.sql2rel.SqlToRelConverter.decorrelate(SqlToRelConverter.java:481) > at > org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:615) > at > org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:177) > at org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334) > at org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317) > at > org.apache.calcite.test.RelOptRulesTest.testDecorrelateWith2ParamsAgg(RelOptRulesTest.java:4286) > 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.
[jira] [Updated] (CALCITE-3121) VolcanoPlanner hangs due to removing ORDER BY from sub-query
[ https://issues.apache.org/jira/browse/CALCITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3121: Labels: pull-request-available (was: ) > VolcanoPlanner hangs due to removing ORDER BY from sub-query > > > Key: CALCITE-3121 > URL: https://issues.apache.org/jira/browse/CALCITE-3121 > Project: Calcite > Issue Type: Bug >Reporter: Bohdan Kazydub >Assignee: Danny Chan >Priority: Blocker > Labels: pull-request-available > > After the fix for CALCITE-2798 some queries hang during planning in > VolcanoPlanner (similar issue was reported in CALCITE-2223). > Here is a test case which should be added to the {{RelOptRulesTest}} class: > {code:java} > @Test public void testSubQueryWithOrderByHang() { > String sql = "select n.n_regionkey from ( select * from " > + "( select * from sales.customer) t order by t.n_regionkey) n where > n.n_nationkey >1 "; > VolcanoPlanner planner = new VolcanoPlanner(null, null); > planner.addRelTraitDef(ConventionTraitDef.INSTANCE); > Tester dynamicTester = createDynamicTester().withDecorrelation(true) > .withClusterFactory( > relOptCluster -> RelOptCluster.create(planner, > relOptCluster.getRexBuilder())); > RelRoot root = dynamicTester.convertSqlToRel(sql); > String planBefore = NL + RelOptUtil.toString(root.rel); > getDiffRepos().assertEquals("planBefore", "${planBefore}", planBefore); > PushProjector.ExprCondition exprCondition = expr -> { > if (expr instanceof RexCall) { > RexCall call = (RexCall) expr; > return > "item".equals(call.getOperator().getName().toLowerCase(Locale.ROOT)); > } > return false; > }; > RuleSet ruleSet = > RuleSets.ofList( > FilterProjectTransposeRule.INSTANCE, > FilterMergeRule.INSTANCE, > ProjectMergeRule.INSTANCE, > new ProjectFilterTransposeRule(Project.class, Filter .class, > RelFactories.LOGICAL_BUILDER, exprCondition), > EnumerableRules.ENUMERABLE_PROJECT_RULE, > EnumerableRules.ENUMERABLE_FILTER_RULE, > EnumerableRules.ENUMERABLE_SORT_RULE, > EnumerableRules.ENUMERABLE_LIMIT_RULE, > EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE); > Program program = Programs.of(ruleSet); > RelTraitSet toTraits = > root.rel.getCluster().traitSet() > .replace(0, EnumerableConvention.INSTANCE); > RelNode relAfter = program.run(planner, root.rel, toTraits, > Collections.emptyList(), Collections.emptyList()); > String planAfter = NL + RelOptUtil.toString(relAfter); > getDiffRepos().assertEquals("planAfter", "${planAfter}", planAfter); > } > {code} > Please note that if {{LIMIT }} is added to the sub-query with order by > (so it is not removed due to the fix for CALCITE-2798) the test succeeds. > Though the issue with hanging is more general, I think that if it wouldn't be > fixed, the fix for CALCITE-2798 should be reverted to reduce cases when > planner may hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3121) VolcanoPlanner hangs due to removing ORDER BY from sub-query
[ https://issues.apache.org/jira/browse/CALCITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859862#comment-16859862 ] Bohdan Kazydub commented on CALCITE-3121: - Reverted CALCITE-2798 and added unit test in [pull request|https://github.com/apache/calcite/pull/1264]. Can someone please review? > VolcanoPlanner hangs due to removing ORDER BY from sub-query > > > Key: CALCITE-3121 > URL: https://issues.apache.org/jira/browse/CALCITE-3121 > Project: Calcite > Issue Type: Bug >Reporter: Bohdan Kazydub >Assignee: Danny Chan >Priority: Blocker > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > After the fix for CALCITE-2798 some queries hang during planning in > VolcanoPlanner (similar issue was reported in CALCITE-2223). > Here is a test case which should be added to the {{RelOptRulesTest}} class: > {code:java} > @Test public void testSubQueryWithOrderByHang() { > String sql = "select n.n_regionkey from ( select * from " > + "( select * from sales.customer) t order by t.n_regionkey) n where > n.n_nationkey >1 "; > VolcanoPlanner planner = new VolcanoPlanner(null, null); > planner.addRelTraitDef(ConventionTraitDef.INSTANCE); > Tester dynamicTester = createDynamicTester().withDecorrelation(true) > .withClusterFactory( > relOptCluster -> RelOptCluster.create(planner, > relOptCluster.getRexBuilder())); > RelRoot root = dynamicTester.convertSqlToRel(sql); > String planBefore = NL + RelOptUtil.toString(root.rel); > getDiffRepos().assertEquals("planBefore", "${planBefore}", planBefore); > PushProjector.ExprCondition exprCondition = expr -> { > if (expr instanceof RexCall) { > RexCall call = (RexCall) expr; > return > "item".equals(call.getOperator().getName().toLowerCase(Locale.ROOT)); > } > return false; > }; > RuleSet ruleSet = > RuleSets.ofList( > FilterProjectTransposeRule.INSTANCE, > FilterMergeRule.INSTANCE, > ProjectMergeRule.INSTANCE, > new ProjectFilterTransposeRule(Project.class, Filter .class, > RelFactories.LOGICAL_BUILDER, exprCondition), > EnumerableRules.ENUMERABLE_PROJECT_RULE, > EnumerableRules.ENUMERABLE_FILTER_RULE, > EnumerableRules.ENUMERABLE_SORT_RULE, > EnumerableRules.ENUMERABLE_LIMIT_RULE, > EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE); > Program program = Programs.of(ruleSet); > RelTraitSet toTraits = > root.rel.getCluster().traitSet() > .replace(0, EnumerableConvention.INSTANCE); > RelNode relAfter = program.run(planner, root.rel, toTraits, > Collections.emptyList(), Collections.emptyList()); > String planAfter = NL + RelOptUtil.toString(relAfter); > getDiffRepos().assertEquals("planAfter", "${planAfter}", planAfter); > } > {code} > Please note that if {{LIMIT }} is added to the sub-query with order by > (so it is not removed due to the fix for CALCITE-2798) the test succeeds. > Though the issue with hanging is more general, I think that if it wouldn't be > fixed, the fix for CALCITE-2798 should be reverted to reduce cases when > planner may hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3121) VolcanoPlanner hangs due to removing ORDER BY from sub-query
[ https://issues.apache.org/jira/browse/CALCITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bohdan Kazydub updated CALCITE-3121: Affects Version/s: 1.19.0 > VolcanoPlanner hangs due to removing ORDER BY from sub-query > > > Key: CALCITE-3121 > URL: https://issues.apache.org/jira/browse/CALCITE-3121 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.19.0 >Reporter: Bohdan Kazydub >Assignee: Danny Chan >Priority: Blocker > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > After the fix for CALCITE-2798 some queries hang during planning in > VolcanoPlanner (similar issue was reported in CALCITE-2223). > Here is a test case which should be added to the {{RelOptRulesTest}} class: > {code:java} > @Test public void testSubQueryWithOrderByHang() { > String sql = "select n.n_regionkey from ( select * from " > + "( select * from sales.customer) t order by t.n_regionkey) n where > n.n_nationkey >1 "; > VolcanoPlanner planner = new VolcanoPlanner(null, null); > planner.addRelTraitDef(ConventionTraitDef.INSTANCE); > Tester dynamicTester = createDynamicTester().withDecorrelation(true) > .withClusterFactory( > relOptCluster -> RelOptCluster.create(planner, > relOptCluster.getRexBuilder())); > RelRoot root = dynamicTester.convertSqlToRel(sql); > String planBefore = NL + RelOptUtil.toString(root.rel); > getDiffRepos().assertEquals("planBefore", "${planBefore}", planBefore); > PushProjector.ExprCondition exprCondition = expr -> { > if (expr instanceof RexCall) { > RexCall call = (RexCall) expr; > return > "item".equals(call.getOperator().getName().toLowerCase(Locale.ROOT)); > } > return false; > }; > RuleSet ruleSet = > RuleSets.ofList( > FilterProjectTransposeRule.INSTANCE, > FilterMergeRule.INSTANCE, > ProjectMergeRule.INSTANCE, > new ProjectFilterTransposeRule(Project.class, Filter .class, > RelFactories.LOGICAL_BUILDER, exprCondition), > EnumerableRules.ENUMERABLE_PROJECT_RULE, > EnumerableRules.ENUMERABLE_FILTER_RULE, > EnumerableRules.ENUMERABLE_SORT_RULE, > EnumerableRules.ENUMERABLE_LIMIT_RULE, > EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE); > Program program = Programs.of(ruleSet); > RelTraitSet toTraits = > root.rel.getCluster().traitSet() > .replace(0, EnumerableConvention.INSTANCE); > RelNode relAfter = program.run(planner, root.rel, toTraits, > Collections.emptyList(), Collections.emptyList()); > String planAfter = NL + RelOptUtil.toString(relAfter); > getDiffRepos().assertEquals("planAfter", "${planAfter}", planAfter); > } > {code} > Please note that if {{LIMIT }} is added to the sub-query with order by > (so it is not removed due to the fix for CALCITE-2798) the test succeeds. > Though the issue with hanging is more general, I think that if it wouldn't be > fixed, the fix for CALCITE-2798 should be reverted to reduce cases when > planner may hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2510) Add CHR built-in function (Oracle only)
[ https://issues.apache.org/jira/browse/CALCITE-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859877#comment-16859877 ] Chunwei Lei commented on CALCITE-2510: -- I rebased and made some fix-up in [https://github.com/chunweilei/calcite/commit/77365bb137742c41c791785a251f00f47b8760bc]. Could someone please have a look? > Add CHR built-in function (Oracle only) > --- > > Key: CALCITE-2510 > URL: https://issues.apache.org/jira/browse/CALCITE-2510 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Sergey Tsvetkov >Assignee: Chunwei Lei >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Adding CHR() function support, available in Oracle & PostgreSql > [https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions019.htm] > [https://www.postgresql.org/docs/9.4/static/functions-string.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3121) VolcanoPlanner hangs due to removing ORDER BY from sub-query
[ https://issues.apache.org/jira/browse/CALCITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860379#comment-16860379 ] Haisheng Yuan commented on CALCITE-3121: I am neutral on reverting previous changes. The bug exists there before CALCITE-2798, but CALCITE-2798 unveiled the issue, for which we don't have a quick fix yet. [~julianhyde] What's your opinion? > VolcanoPlanner hangs due to removing ORDER BY from sub-query > > > Key: CALCITE-3121 > URL: https://issues.apache.org/jira/browse/CALCITE-3121 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.19.0 >Reporter: Bohdan Kazydub >Assignee: Danny Chan >Priority: Blocker > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > After the fix for CALCITE-2798 some queries hang during planning in > VolcanoPlanner (similar issue was reported in CALCITE-2223). > Here is a test case which should be added to the {{RelOptRulesTest}} class: > {code:java} > @Test public void testSubQueryWithOrderByHang() { > String sql = "select n.n_regionkey from ( select * from " > + "( select * from sales.customer) t order by t.n_regionkey) n where > n.n_nationkey >1 "; > VolcanoPlanner planner = new VolcanoPlanner(null, null); > planner.addRelTraitDef(ConventionTraitDef.INSTANCE); > Tester dynamicTester = createDynamicTester().withDecorrelation(true) > .withClusterFactory( > relOptCluster -> RelOptCluster.create(planner, > relOptCluster.getRexBuilder())); > RelRoot root = dynamicTester.convertSqlToRel(sql); > String planBefore = NL + RelOptUtil.toString(root.rel); > getDiffRepos().assertEquals("planBefore", "${planBefore}", planBefore); > PushProjector.ExprCondition exprCondition = expr -> { > if (expr instanceof RexCall) { > RexCall call = (RexCall) expr; > return > "item".equals(call.getOperator().getName().toLowerCase(Locale.ROOT)); > } > return false; > }; > RuleSet ruleSet = > RuleSets.ofList( > FilterProjectTransposeRule.INSTANCE, > FilterMergeRule.INSTANCE, > ProjectMergeRule.INSTANCE, > new ProjectFilterTransposeRule(Project.class, Filter .class, > RelFactories.LOGICAL_BUILDER, exprCondition), > EnumerableRules.ENUMERABLE_PROJECT_RULE, > EnumerableRules.ENUMERABLE_FILTER_RULE, > EnumerableRules.ENUMERABLE_SORT_RULE, > EnumerableRules.ENUMERABLE_LIMIT_RULE, > EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE); > Program program = Programs.of(ruleSet); > RelTraitSet toTraits = > root.rel.getCluster().traitSet() > .replace(0, EnumerableConvention.INSTANCE); > RelNode relAfter = program.run(planner, root.rel, toTraits, > Collections.emptyList(), Collections.emptyList()); > String planAfter = NL + RelOptUtil.toString(relAfter); > getDiffRepos().assertEquals("planAfter", "${planAfter}", planAfter); > } > {code} > Please note that if {{LIMIT }} is added to the sub-query with order by > (so it is not removed due to the fix for CALCITE-2798) the test succeeds. > Though the issue with hanging is more general, I think that if it wouldn't be > fixed, the fix for CALCITE-2798 should be reverted to reduce cases when > planner may hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[ https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860487#comment-16860487 ] Forward Xu commented on CALCITE-3005: - hi [~julianhyde] Thank you very much, this is my fault. > Implement string functions: LEFT, RIGHT > --- > > Key: CALCITE-3005 > URL: https://issues.apache.org/jira/browse/CALCITE-3005 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Some string functions including LEFT, RIGHT are not implemented now. It would > be great if these functions can be implemented. > [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left] > Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. > [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right] > Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3073) Support to consume from timestamp in KafkaAdapter
[ https://issues.apache.org/jira/browse/CALCITE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860493#comment-16860493 ] Matt Wang commented on CALCITE-3073: [~mingmxu] I think it's reasonable if user want to use this *{color:#707070}MSG_TIMESTAMP{color}* field, he has to define it. And adding a special reserved keyword(`KAFKA_TIMESTAMP`) in KafkaAdapter maybe too special. > Support to consume from timestamp in KafkaAdapter > - > > Key: CALCITE-3073 > URL: https://issues.apache.org/jira/browse/CALCITE-3073 > Project: Calcite > Issue Type: Improvement > Components: kafka-adapter >Reporter: Xu Mingmin >Assignee: Matt Wang >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently the KafkaAdapter consumes data from default > offset(latest/earliest/last_offset) and runs forever. > In other words, if the app runs at first time and user want to consume the > past data, user must set the value of > '{color:#707070}*auto.offset.reset'*{color} parameter to *earliest*. > {quote}{{auto.offset.reset:What to do when there is no initial offset in > Kafka or if the current offset does not exist any more on the server (e.g. > because that data has been deleted):}} > * earliest: automatically reset the offset to the earliest offset > * latest: automatically reset the offset to the latest offset > * none: throw exception to the consumer if no previous offset is found for > the consumer's group > * anything else: throw exception to the consumer.{quote} > for example, suppose data in Kafka is retained for 7 days and you just want > to read from the data of yesterday, if you could not control the start > timestamp, you can only read from the earliest offset, it's very inefficient. > If supporting to consume from special timestamp in KafkaAdapter will be a > good idea for some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3005) Implement string functions: LEFT, RIGHT
[ https://issues.apache.org/jira/browse/CALCITE-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860532#comment-16860532 ] Julian Hyde commented on CALCITE-3005: -- Thanks for taking responsibility, but it was me: I removed the {{LOOAKAHEAD(1)}} from the parser while merging your change because I did a quick test and it didn't seem to be necessary; I was wrong. > Implement string functions: LEFT, RIGHT > --- > > Key: CALCITE-3005 > URL: https://issues.apache.org/jira/browse/CALCITE-3005 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Some string functions including LEFT, RIGHT are not implemented now. It would > be great if these functions can be implemented. > [{{LEFT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_left] > Returns the leftmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. > [{{RIGHT(_str_}},_{{len}}_)|https://dev.mysql.com/doc/refman/8.0/en/string-functions.html#function_right] > Returns the rightmost _{{len}}_ characters from the string _{{str}}_, or > {{NULL}} if any argument is {{NULL}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)