[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)
