[jira] [Comment Edited] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916089#comment-16916089 ] Julian Hyde edited comment on CALCITE-3122 at 8/27/19 3:18 AM: --- The failed test is not critical. The reason is somehow CALCITE-3138 prevents my rule PigToSqlAggregateRule from being applied to produced a bit more optimized plan for multiset projection. But with the non-optimized plan, we can still execute and produce SQL for it. I added a TODO in [this commit|https://github.com/khaitranq/calcite-1/commit/200f5b5462bfa6439afecc1238ad2e63d3282462] as I'm not sure if it's worth to create a JIRA. We just miss a minor optimization for an uncommon use case. was (Author: khaitran): The failed test is not critical. The reason is somehow CALCITE 3138 prevents my rule PigToSqlAggregateRule from being applied to produced a bit more optimized plan for multiset projection. But with the non-optimized plan, we can still execute and produce SQL for it. I added a TODO in [this commit|https://github.com/khaitranq/calcite-1/commit/200f5b5462bfa6439afecc1238ad2e63d3282462] as I'm not sure if it's worth to create a JIRA. We just miss a minor optimization for an uncommon use case. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (CALCITE-3283) RelSubSet's best is not existed in the set
[
https://issues.apache.org/jira/browse/CALCITE-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan resolved CALCITE-3283.
Fix Version/s: 1.21.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/77e7808fc0aa4e089a992535bc890047724fd900,
thanks for the PR, [~xndai]!
> RelSubSet's best is not existed in the set
> --
>
> Key: CALCITE-3283
> URL: https://issues.apache.org/jira/browse/CALCITE-3283
> Project: Calcite
> Issue Type: Bug
>Reporter: Xiening Dai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> To repro this, add below code in VolcanoPlanner.isValid() which verifies
> RelSubset.best indeed belongs to its set -
> {code:java}
> // Make sure best RelNode is valid
> if (subset.best != null && !subset.set.rels.contains(subset.best)) {
> return litmus.fail("RelSubSet [{}] has best RelNode [{}] which is
> not existed in its set.",
> subset.getDescription(), subset.best.getDescription());
> }
> {code}
> Run JDBCTest.testVarcharEquals, you will get below exception -
> java.lang.AssertionError: RelSubSet [rel#6828:Subset#2.JDBC.foodmart.[]] has
> best RelNode
> [rel#6871:JdbcProject.JDBC.foodmart.[](input=RelSubset#6844,lname=$2)] which
> is not existed in its set.
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.isValid(VolcanoPlanner.java:888)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:851)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:868)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1939)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:129)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:236)
> at
> org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:141)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:286)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:346)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:189)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:320)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:638)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:502)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:472)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1466)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1398)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1464)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1447)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1410)
> at
> org.apache.calcite.test.JdbcTest.testVarcharEquals(JdbcTest.java:4420)
> 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
>
[jira] [Updated] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-2772:
Labels: pull-request-available (was: )
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916197#comment-16916197 ] Khai Tran commented on CALCITE-3122: Ok, created CALCITE-3297 for that and updated the comment. I commented out the expectedOptimizedPlan and left it there so that anyone works on that later know how the optimized plan looks like. Please do not disable the test as other parts like testing non-optimized plan, execute and produce results for non-optimized plan are still needed. Just include my two latest commits in my pull request. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3297) PigToSqlAggregateRule should be applied on multi-set projection to produce an optimal plan
Khai Tran created CALCITE-3297: -- Summary: PigToSqlAggregateRule should be applied on multi-set projection to produce an optimal plan Key: CALCITE-3297 URL: https://issues.apache.org/jira/browse/CALCITE-3297 Project: Calcite Issue Type: Bug Components: piglet Reporter: Khai Tran Fixed testMultisetProjection() in PigRelOpTest.java to make sure the PigToSqlAggregateRule is applied to produce an optimized plan for doing multiset projection after COLLECT() agg func. The optimization rule was blocked by change in CALCITE-3138. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3193) Add RelBuilder.uncollect method, and interface UncollectFactory, to instantiate Uncollect
[
https://issues.apache.org/jira/browse/CALCITE-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3193:
-
Summary: Add RelBuilder.uncollect method, and interface UncollectFactory,
to instantiate Uncollect (was: Move Uncollect from LogicalPigRelBuilder to
RelBuilder)
> Add RelBuilder.uncollect method, and interface UncollectFactory, to
> instantiate Uncollect
> -
>
> Key: CALCITE-3193
> URL: https://issues.apache.org/jira/browse/CALCITE-3193
> Project: Calcite
> Issue Type: Improvement
> Components: core, piglet
>Reporter: Khai Tran
>Priority: Minor
>
> {{Uncollect}} is a rarely used sub-class of {{RelNode}}, but it should have a
> method {{RelBuilder.uncollect()}} and {{interface UncollectFactory}} in
> {{RelFactories}}.
> Change {{PigRelBuilder.multiSetFlatten()}} and other code to use it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3193) Move Uncollect from LogicalPigRelBuilder to RelBuilder
[
https://issues.apache.org/jira/browse/CALCITE-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3193:
-
Description:
{{Uncollect}} is a rarely used sub-class of {{RelNode}}, but it should have a
method {{RelBuilder.uncollect()}} and {{interface UncollectFactory}} in
{{RelFactories}}.
Change {{PigRelBuilder.multiSetFlatten()}} and other code to use it.
was:Implementation of uncollect in LogicalPigRelBuilder should be moved to
RelBuilder for other use cases
> Move Uncollect from LogicalPigRelBuilder to RelBuilder
> --
>
> Key: CALCITE-3193
> URL: https://issues.apache.org/jira/browse/CALCITE-3193
> Project: Calcite
> Issue Type: Improvement
> Components: core, piglet
>Reporter: Khai Tran
>Priority: Minor
>
> {{Uncollect}} is a rarely used sub-class of {{RelNode}}, but it should have a
> method {{RelBuilder.uncollect()}} and {{interface UncollectFactory}} in
> {{RelFactories}}.
> Change {{PigRelBuilder.multiSetFlatten()}} and other code to use it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916176#comment-16916176 ] Julian Hyde commented on CALCITE-3122: -- I don't like TODOs. They rarely get done, and the users who are hurt by them never see them. Can you please log a bug? I'll merge with that test disabled. I think it's a fairly important feature (you clearly spent a considerable amount of effort on it) so I'd like to get it working again soon. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3296) Decorrelator gives empty result after decorrelating sort rel with null offset and fetch
[ https://issues.apache.org/jira/browse/CALCITE-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916095#comment-16916095 ] Juhwan Kim commented on CALCITE-3296: - [~julianhyde] Yes. Here is the link for the commit(https://github.com/apache/calcite/commit/6f6d03bca7cd97d151033c5d82f24394e229). > Decorrelator gives empty result after decorrelating sort rel with null offset > and fetch > --- > > Key: CALCITE-3296 > URL: https://issues.apache.org/jira/browse/CALCITE-3296 > Project: Calcite > Issue Type: Bug >Reporter: Juhwan Kim >Assignee: Juhwan Kim >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > It seems like I introduced a bug with the recent decorrelator patch. Sort rel > with null offset and fetch would end up becoming an empty value since > decorrelator would call sortLimit builder with 0 limit and 0 offset. It > should pass negative values to builder when values are null. > https://github.com/apache/calcite/blob/e863294ccfbed9dd520c999f75ed0bbe03f9fb1d/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L423 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916092#comment-16916092 ] Khai Tran commented on CALCITE-3122: [~julianhyde] Aslo, I created MULTISET_PROJECTION operator and its runtime implementation in piglet, but I think we should add it to StdSqlOperatorTable in core for other use cases later. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916089#comment-16916089 ] Khai Tran commented on CALCITE-3122: The failed test is not critical. The reason is somehow CALCITE 3138 prevents my rule PigToSqlAggregateRule from being applied to produced a bit more optimized plan for multiset projection. But with the non-optimized plan, we can still execute and produce SQL for it. I added a TODO in [this commit|https://github.com/khaitranq/calcite-1/commit/200f5b5462bfa6439afecc1238ad2e63d3282462] as I'm not sure if it's worth to create a JIRA. We just miss a minor optimization for an uncommon use case. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3280) Cannot parse query REGEXP_REPLACE in Redshift
[
https://issues.apache.org/jira/browse/CALCITE-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3280:
-
Fix Version/s: 1.21.0
> Cannot parse query REGEXP_REPLACE in Redshift
> -
>
> Key: CALCITE-3280
> URL: https://issues.apache.org/jira/browse/CALCITE-3280
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ryan Fu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> REGEXP_REPLACE error:
> {code:}
> No match found for function signature REGEXP_REPLACE(,
> , ){code}
>
> Example query:
> {code:sql}
> SELECT * , MD5(TRIM(BOTH ' ' FROM REGEXP_REPLACE(LOWER(name),
> '([[:space:]]|,)+([iInNcC]|[lLcC]).*$', ''))) AS company_id FROM
> public.account {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CALCITE-3280) Cannot parse query REGEXP_REPLACE in Redshift
[
https://issues.apache.org/jira/browse/CALCITE-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3280:
Assignee: Julian Hyde
> Cannot parse query REGEXP_REPLACE in Redshift
> -
>
> Key: CALCITE-3280
> URL: https://issues.apache.org/jira/browse/CALCITE-3280
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ryan Fu
>Assignee: Julian Hyde
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> REGEXP_REPLACE error:
> {code:}
> No match found for function signature REGEXP_REPLACE(,
> , ){code}
>
> Example query:
> {code:sql}
> SELECT * , MD5(TRIM(BOTH ' ' FROM REGEXP_REPLACE(LOWER(name),
> '([[:space:]]|,)+([iInNcC]|[lLcC]).*$', ''))) AS company_id FROM
> public.account {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3280) Cannot parse query REGEXP_REPLACE in Redshift
[
https://issues.apache.org/jira/browse/CALCITE-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916079#comment-16916079
]
Julian Hyde commented on CALCITE-3280:
--
Reviewing now.
> Cannot parse query REGEXP_REPLACE in Redshift
> -
>
> Key: CALCITE-3280
> URL: https://issues.apache.org/jira/browse/CALCITE-3280
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ryan Fu
>Assignee: Julian Hyde
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> REGEXP_REPLACE error:
> {code:}
> No match found for function signature REGEXP_REPLACE(,
> , ){code}
>
> Example query:
> {code:sql}
> SELECT * , MD5(TRIM(BOTH ' ' FROM REGEXP_REPLACE(LOWER(name),
> '([[:space:]]|,)+([iInNcC]|[lLcC]).*$', ''))) AS company_id FROM
> public.account {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3293) Add strcmp function
[
https://issues.apache.org/jira/browse/CALCITE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916075#comment-16916075
]
Julian Hyde commented on CALCITE-3293:
--
Please add description.
Please start JIRA case one-line summary with a capital letter, but do not end
with period ('.'). Same for commit message.
Is this a SQL function? If SQL, use upper-case. Is it standard, or state which
dialects.
Don't use {{assert}} in tests. It gets switched off if asserts are disabled.
Use {{Assert.assertThat}}.
> Add strcmp function
> ---
>
> Key: CALCITE-3293
> URL: https://issues.apache.org/jira/browse/CALCITE-3293
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Add strcmp function.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3288) linq4j: support Set literals
[ https://issues.apache.org/jira/browse/CALCITE-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916069#comment-16916069 ] Julian Hyde commented on CALCITE-3288: -- Ah, I know. The hashCode of Integer is the integer itself. So, you were very very lucky. Let's have a test that uses strings, or integers not in ascending order. Then you'll probably have to use LinkedHashSet to achieve determinism. > linq4j: support Set literals > > > Key: CALCITE-3288 > URL: https://issues.apache.org/jira/browse/CALCITE-3288 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3288) linq4j: support Set literals
[ https://issues.apache.org/jira/browse/CALCITE-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916066#comment-16916066 ] Julian Hyde commented on CALCITE-3288: -- Please add a description. Why are there two PRs? I am surprised that this test passes (even more surprised that it passes on multiple JDK versions). The test adds multiple elements to a HashSet. The order that those values will come out of the HashSet is undetermined, yet the test asserts that they come out in a particular order. Can you explain why you believe the test is deterministic? > linq4j: support Set literals > > > Key: CALCITE-3288 > URL: https://issues.apache.org/jira/browse/CALCITE-3288 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3296) Decorrelator gives empty result after decorrelating sort rel with null offset and fetch
[ https://issues.apache.org/jira/browse/CALCITE-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916059#comment-16916059 ] Julian Hyde commented on CALCITE-3296: -- Can you please link to the fix that caused this? > Decorrelator gives empty result after decorrelating sort rel with null offset > and fetch > --- > > Key: CALCITE-3296 > URL: https://issues.apache.org/jira/browse/CALCITE-3296 > Project: Calcite > Issue Type: Bug >Reporter: Juhwan Kim >Assignee: Juhwan Kim >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > It seems like I introduced a bug with the recent decorrelator patch. Sort rel > with null offset and fetch would end up becoming an empty value since > decorrelator would call sortLimit builder with 0 limit and 0 offset. It > should pass negative values to builder when values are null. > https://github.com/apache/calcite/blob/e863294ccfbed9dd520c999f75ed0bbe03f9fb1d/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L423 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916057#comment-16916057 ] Khai Tran commented on CALCITE-3122: [~julianhyde] and [~IhorHuzenko]: let me try to see if I can make a quick fix. > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3260) Add a public API for evaluating linq4j Expression nodes
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916056#comment-16916056 ] Julian Hyde commented on CALCITE-3260: -- Reviewing now. > Add a public API for evaluating linq4j Expression nodes > --- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Assignee: Julian Hyde >Priority: Minor > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (CALCITE-3260) Add a public API for evaluating linq4j Expression nodes
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde reassigned CALCITE-3260: Assignee: Julian Hyde > Add a public API for evaluating linq4j Expression nodes > --- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Assignee: Julian Hyde >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3260) Add a public API for evaluating linq4j Expression nodes
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3260: - Fix Version/s: 1.21.0 > Add a public API for evaluating linq4j Expression nodes > --- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Assignee: Julian Hyde >Priority: Minor > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3296) Decorrelator gives empty result after decorrelating sort rel with null offset and fetch
[ https://issues.apache.org/jira/browse/CALCITE-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3296: Labels: pull-request-available (was: ) > Decorrelator gives empty result after decorrelating sort rel with null offset > and fetch > --- > > Key: CALCITE-3296 > URL: https://issues.apache.org/jira/browse/CALCITE-3296 > Project: Calcite > Issue Type: Bug >Reporter: Juhwan Kim >Assignee: Juhwan Kim >Priority: Major > Labels: pull-request-available > > It seems like I introduced a bug with the recent decorrelator patch. Sort rel > with null offset and fetch would end up becoming an empty value since > decorrelator would call sortLimit builder with 0 limit and 0 offset. It > should pass negative values to builder when values are null. > https://github.com/apache/calcite/blob/e863294ccfbed9dd520c999f75ed0bbe03f9fb1d/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L423 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3296) Decorrelator gives empty result after decorrelating sort rel with null offset and fetch
Juhwan Kim created CALCITE-3296: --- Summary: Decorrelator gives empty result after decorrelating sort rel with null offset and fetch Key: CALCITE-3296 URL: https://issues.apache.org/jira/browse/CALCITE-3296 Project: Calcite Issue Type: Bug Reporter: Juhwan Kim Assignee: Juhwan Kim It seems like I introduced a bug with the recent decorrelator patch. Sort rel with null offset and fetch would end up becoming an empty value since decorrelator would call sortLimit builder with 0 limit and 0 offset. It should pass negative values to builder when values are null. https://github.com/apache/calcite/blob/e863294ccfbed9dd520c999f75ed0bbe03f9fb1d/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java#L423 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3260) Add a public API for evaluating linq4j Expression nodes
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3260: - Summary: Add a public API for evaluating linq4j Expression nodes (was: Add support of evaluate method with default Evaluator.) > Add a public API for evaluating linq4j Expression nodes > --- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[
https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916028#comment-16916028
]
Julian Hyde edited comment on CALCITE-3122 at 8/26/19 6:27 PM:
---
Houston, we have a problem.
I have partially squashed and rebased; see [my 3122-pig
branch|https://github.com/julianhyde/calcite/tree/3122-pig] (commit
[fad7b47f|https://github.com/julianhyde/calcite/commit/fad7b47ff28ef3435ae391b1681ab6413ec744f9]).
But once I rebase to pull in CALCITE-3138 (commit
[1e62d3d64|https://github.com/apache/calcite/commit/1e62d3d64fc217d14016702237b4f8d56b3683f2])
then {{PigRelOpTest.testMultisetProjection}} breaks.
[~khaitran] and [~IhorHuzenko] (as author of CALCITE-3138), can you please work
together to figure out why your changes are incompatible.
[~khaitran], We need to merge a fix to master in about the next 12 hours if we
are going to make it into release 1.21. If you would like to disable
{{testMultisetProjection}} let me know.
was (Author: julianhyde):
Houston, we have a problem.
I have partially squashed and rebased; see [my 3122-pig
branch|https://github.com/julianhyde/calcite/tree/3122-pig] (commit
[fad7b47f|https://github.com/julianhyde/calcite/commit/fad7b47ff28ef3435ae391b1681ab6413ec744f9].
But once I rebase to pull in CALCITE-3138 (commit
[1e62d3d64|https://github.com/apache/calcite/commit/1e62d3d64fc217d14016702237b4f8d56b3683f2])
then {{PigRelOpTest.testMultisetProjection}} breaks.
[~khaitran] and [~IhorHuzenko] (as author of CALCITE-3138), can you please work
together to figure out why your changes are incompatible.
[~khaitran], We need to merge a fix to master in about the next 12 hours if we
are going to make it into release 1.21. If you would like to disable
{{testMultisetProjection}} let me know.
> Convert Pig Latin scripts into Calcite logical plan
>
>
> Key: CALCITE-3122
> URL: https://issues.apache.org/jira/browse/CALCITE-3122
> Project: Calcite
> Issue Type: New Feature
> Components: core, piglet
>Reporter: Khai Tran
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We create an internal Calcite repo at LinkedIn and develop APIs to parse any
> Pig Latin scripts into Calcite logical plan. The code was tested in nearly
> ~1000 Pig scripts written at LinkedIn.
> Changes:
> 1. piglet: main conversion code live there, include:
> * APIs to convert any Pig scripts into RelNode plans or SQL statements
> * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan
> (DAGs)
> * Convert Pig schemas into RelDatatype
> * Traverse through Pig expression plan and convert Pig expressions into
> RexNodes
> * Map some basic Pig UDFs to Calcite SQL operators
> * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both
> Java and Python
> * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes
> to RelNodes
> * Have an optimizer rule to optimize Pig group/cogroup into Aggregate
> operators
> 2. core:
> * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL
> * Other minor changes in a few other classes to make Pig to Calcite works
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[
https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916028#comment-16916028
]
Julian Hyde commented on CALCITE-3122:
--
Houston, we have a problem.
I have partially squashed and rebased; see [my 3122-pig
branch|https://github.com/julianhyde/calcite/tree/3122-pig] (commit
[fad7b47f|https://github.com/julianhyde/calcite/commit/fad7b47ff28ef3435ae391b1681ab6413ec744f9].
But once I rebase to pull in CALCITE-3138 (commit
[1e62d3d64|https://github.com/apache/calcite/commit/1e62d3d64fc217d14016702237b4f8d56b3683f2])
then {{PigRelOpTest.testMultisetProjection}} breaks.
[~khaitran] and [~IhorHuzenko] (as author of CALCITE-3138), can you please work
together to figure out why your changes are incompatible.
[~khaitran], We need to merge a fix to master in about the next 12 hours if we
are going to make it into release 1.21. If you would like to disable
{{testMultisetProjection}} let me know.
> Convert Pig Latin scripts into Calcite logical plan
>
>
> Key: CALCITE-3122
> URL: https://issues.apache.org/jira/browse/CALCITE-3122
> Project: Calcite
> Issue Type: New Feature
> Components: core, piglet
>Reporter: Khai Tran
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We create an internal Calcite repo at LinkedIn and develop APIs to parse any
> Pig Latin scripts into Calcite logical plan. The code was tested in nearly
> ~1000 Pig scripts written at LinkedIn.
> Changes:
> 1. piglet: main conversion code live there, include:
> * APIs to convert any Pig scripts into RelNode plans or SQL statements
> * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan
> (DAGs)
> * Convert Pig schemas into RelDatatype
> * Traverse through Pig expression plan and convert Pig expressions into
> RexNodes
> * Map some basic Pig UDFs to Calcite SQL operators
> * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both
> Java and Python
> * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes
> to RelNodes
> * Have an optimizer rule to optimize Pig group/cogroup into Aggregate
> operators
> 2. core:
> * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL
> * Other minor changes in a few other classes to make Pig to Calcite works
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3295) Aggregate call name lost in serialized json string.
[
https://issues.apache.org/jira/browse/CALCITE-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3295:
Labels: pull-request-available (was: )
> Aggregate call name lost in serialized json string.
> ---
>
> Key: CALCITE-3295
> URL: https://issues.apache.org/jira/browse/CALCITE-3295
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
>
> When serialize a relnode to json string, the name of aggregate call was lost.
> For a sql string like this
> {code:java}
> SELECT max(SAL) as max_sal from EMP group by JOB;
> {code}
> The serialized json string is like this
> {code:java}
> {
> "rels": [
> {
> "id": "0",
> "relOp": "LogicalTableScan",
> "table": [
> "scott",
> "EMP"
> ],
> "inputs": []
> },
> {
> "id": "1",
> "relOp": "LogicalProject",
> "fields": [
> "JOB",
> "SAL"
> ],
> "exprs": [
> {
> "input": 2,
> "name": "$2"
> },
> {
> "input": 5,
> "name": "$5"
> }
> ]
> },
> {
> "id": "2",
> "relOp": "LogicalAggregate",
> "group": [
> 0
> ],
> "aggs": [
> {
> "agg": {
> "name": "MAX",
> "kind": "MAX",
> "syntax": "FUNCTION"
> },
> "type": {
> "type": "DECIMAL",
> "nullable": true,
> "precision": 7,
> "scale": 2
> },
> "distinct": false,
> "operands": [
> 1
> ],
> }
> ]
> },
> {
> "id": "3",
> "relOp": "LogicalProject",
> "fields": [
> "max_sal"
> ],
> "exprs": [
> {
> "input": 1,
> "name": "$1"
> }
> ]
> }
> ]
> }
> {code}
> Lost the name of max call.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3295) Aggregate call name lost in serialized json string.
Wang Yanlin created CALCITE-3295:
Summary: Aggregate call name lost in serialized json string.
Key: CALCITE-3295
URL: https://issues.apache.org/jira/browse/CALCITE-3295
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When serialize a relnode to json string, the name of aggregate call was lost.
For a sql string like this
{code:java}
SELECT max(SAL) as max_sal from EMP group by JOB;
{code}
The serialized json string is like this
{code:java}
{
"rels": [
{
"id": "0",
"relOp": "LogicalTableScan",
"table": [
"scott",
"EMP"
],
"inputs": []
},
{
"id": "1",
"relOp": "LogicalProject",
"fields": [
"JOB",
"SAL"
],
"exprs": [
{
"input": 2,
"name": "$2"
},
{
"input": 5,
"name": "$5"
}
]
},
{
"id": "2",
"relOp": "LogicalAggregate",
"group": [
0
],
"aggs": [
{
"agg": {
"name": "MAX",
"kind": "MAX",
"syntax": "FUNCTION"
},
"type": {
"type": "DECIMAL",
"nullable": true,
"precision": 7,
"scale": 2
},
"distinct": false,
"operands": [
1
],
}
]
},
{
"id": "3",
"relOp": "LogicalProject",
"fields": [
"max_sal"
],
"exprs": [
{
"input": 1,
"name": "$1"
}
]
}
]
}
{code}
Lost the name of max call.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3243) Incomplete validation of operands in JSON functions
[
https://issues.apache.org/jira/browse/CALCITE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3243:
Labels: pull-request-available (was: )
> Incomplete validation of operands in JSON functions
> -
>
> Key: CALCITE-3243
> URL: https://issues.apache.org/jira/browse/CALCITE-3243
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Stamatis Zampetakis
>Assignee: Matt Wang
>Priority: Major
> Labels: pull-request-available
>
> The operands of various JSON functions are not validated correctly.
> Consider for instance the {{JSON_VALUE}} function and the following calls:
> {code:sql}
> json_value('{\"foo\":100}', 'strict $.foo')"
> json_value(1, 'strict $.foo')"
> json_value(TRUE, 'strict $.foo')"
> {code}
> The first call is legal but the next are not; if I am not wrong the operands
> should be always CHAR or VARCHAR literals which is not the case above.
> Queries involving such calls fail at runtime when compiling generated code. I
> guess that such kind of problems should be captured by the validator and we
> should not even arrive at the code generation step.
> The problems can be easily reproduced by adding such calls in the
> {{SqlOperatorBaseTest}}.
> The problem does not only affect {{JSON_VALUE}} but other JSON functions
> (such as {{JSON_QUERY}} etc.) as well.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3290) evaluate in AbstractNode
[ https://issues.apache.org/jira/browse/CALCITE-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3290: Labels: pull-request-available (was: ) > evaluate in AbstractNode > > > Key: CALCITE-3290 > URL: https://issues.apache.org/jira/browse/CALCITE-3290 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > Labels: pull-request-available > > we could implement the expressions evaluate in AbstractNode directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3294) Implement FINAL Clause for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915742#comment-16915742
]
Julian Feinauer commented on CALCITE-3294:
--
[~julianhyde] I could imagine working on that (although I have not that much
time atm, just as a warning). But I would like to have your insights or ideas
on how to implement that. My first idea is to treat it somewhat similar to how
the Window Aggreation works as it should be really similar under the covers.
Any ideas?
> Implement FINAL Clause for MATCH_RECOGNIZE
> --
>
> Key: CALCITE-3294
> URL: https://issues.apache.org/jira/browse/CALCITE-3294
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Feinauer
>Priority: Major
>
> With CALCITE-1935 the initial support for the MATCH_RECOGNIZE clause was
> introduced. But it is still lacking several features.
> One of them is the FINAL Clause which forces the `MEASURE` to act global on
> all Tuples which were matched by the pattern.
> See
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1
> An example query would be:
> {code}
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> ORDER BY tstamp
> MEASURES
>LAST(A.tstamp) AS ts_prev,
>FINAL LAST(A.tstamp) AS ts_last
> ALL ROWS PER MATCH
> PATTERN (A+)
> DEFINE
>A AS A.units_sold > 10
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> {code}
> Here, the query matches for each sequence of rows which all have `units_sold
> > 10`.
> For the column `ts_prev` it always shows the timestamp of the timestamp of
> the previous match (the row before).
> But for `ts_last` it shows the SAME value for each column as the `FINAL`
> modifier changes teh behavior to apply the `LAST` operator to the record set
> (similar to a window aggregation on the machted subset of rows).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3294) Implement FINAL Clause for MATCH_RECOGNIZE
Julian Feinauer created CALCITE-3294:
Summary: Implement FINAL Clause for MATCH_RECOGNIZE
Key: CALCITE-3294
URL: https://issues.apache.org/jira/browse/CALCITE-3294
Project: Calcite
Issue Type: Improvement
Reporter: Julian Feinauer
With CALCITE-1935 the initial support for the MATCH_RECOGNIZE clause was
introduced. But it is still lacking several features.
One of them is the FINAL Clause which forces the `MEASURE` to act global on all
Tuples which were matched by the pattern.
See
https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1
An example query would be:
{code}
SELECT *
FROM sales_history MATCH_RECOGNIZE (
ORDER BY tstamp
MEASURES
LAST(A.tstamp) AS ts_prev,
FINAL LAST(A.tstamp) AS ts_last
ALL ROWS PER MATCH
PATTERN (A+)
DEFINE
A AS A.units_sold > 10
) MR
ORDER BY MR.product, MR.start_tstamp;
{code}
Here, the query matches for each sequence of rows which all have `units_sold >
10`.
For the column `ts_prev` it always shows the timestamp of the timestamp of the
previous match (the row before).
But for `ts_last` it shows the SAME value for each column as the `FINAL`
modifier changes teh behavior to apply the `LAST` operator to the record set
(similar to a window aggregation on the machted subset of rows).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CALCITE-3210) JDBC adapter should generate "CAST(NULL AS type)" rather than "NULL"
[
https://issues.apache.org/jira/browse/CALCITE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan resolved CALCITE-3210.
-
Fix Version/s: (was: next)
1.21.0
Resolution: Fixed
Fixed in
[e863294|https://github.com/apache/calcite/commit/e863294ccfbed9dd520c999f75ed0bbe03f9fb1d],
thanks for your PR, [~wangweidong] !
> JDBC adapter should generate "CAST(NULL AS type)" rather than "NULL"
>
>
> Key: CALCITE-3210
> URL: https://issues.apache.org/jira/browse/CALCITE-3210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
> Environment: mac os
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> I have as sql as follows:
> {code:java}
> select cast(null as varchar) as a{code}
> The process step is :
> # parse sql to SqlNode;
> # convert SqlNode to RelNode;
> # convert RelNode to SqlNode;
> # convert SqlNode to string.
> The result string is:
> {code:java}
> "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
> Finally, I found that the result string is absent of cast statement for
> "null" which causes the result sql to be invalid.
> Actually, the result I expect is like:
> {code:java}
> "SELECT CAST(NULL AS VARCHAR) AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
>
> Testing code is as follows
> {code:java}
> // code placeholder
> @Test
> public void testSeletNull() throws SqlParseException {
> String sql = "select cast(null as varchar) as a";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> Assert.assertEquals(sqlNodeNew.toString(), "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)");
> }
> private static SqlNode toSqlNode(RelNode root) {
> SqlDialect dialect = MysqlSqlDialect.DEFAULT;
> RelToSqlConverter converter = new RelToSqlConverter(dialect == null ?
> dialect : dialect);
> return converter.visitChild(0, root).asStatement();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915562#comment-16915562 ] Lai Zhou commented on CALCITE-3284: --- yes, you're right. I have pushed a new commit, which resolved this issue. > Enumerable hash semijoin / antijoin support non-equi join conditions > > > Key: CALCITE-3284 > URL: https://issues.apache.org/jira/browse/CALCITE-3284 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Priority: Major > > Calcite should be able to generate enumerable hash semijoin / antijoin with > non-equi join conditions, as long as there are equi-join condtions, so that > we can do hash look up. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3289) Disable test pending fix for Wikipedia format change
[ https://issues.apache.org/jira/browse/CALCITE-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xzh_dz updated CALCITE-3289: Description: !image-2019-08-24-20-35-39-763.png|width=522,height=112! org.junit.AssumptionViolatedException: got: , expected: is org.junit.AssumptionViolatedException: got: , expected: is at org.junit.Assume.assumeThat(Assume.java:95) at org.junit.Assume.assumeTrue(Assume.java:41) at org.apache.calcite.adapter.file.FileReaderTest.testFileReaderUrlNoPath(FileReaderTest.java:72) 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) was:!image-2019-08-24-20-35-39-763.png|width=522,height=112! > Disable test pending fix for Wikipedia format change > > > Key: CALCITE-3289 > URL: https://issues.apache.org/jira/browse/CALCITE-3289 > Project: Calcite > Issue Type: Test >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > Attachments: image-2019-08-24-20-35-39-763.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2019-08-24-20-35-39-763.png|width=522,height=112! > org.junit.AssumptionViolatedException: got: , expected: is > org.junit.AssumptionViolatedException: got: , expected: is > at org.junit.Assume.assumeThat(Assume.java:95) at > org.junit.Assume.assumeTrue(Assume.java:41) at > org.apache.calcite.adapter.file.FileReaderTest.testFileReaderUrlNoPath(FileReaderTest.java:72) > 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) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915539#comment-16915539
]
Ruben Quesada Lopez edited comment on CALCITE-3284 at 8/26/19 7:39 AM:
---
[~hhlai1990], you can create the test using RelBuilder (see
{{EnumerableJoinTest#equiAntiJoin}}, {{EnumerableJoinTest#nonEquiAntiJoin}}).
Unfortunately, I think it is not possible to create tests in SQL, since the SQL
parser does not generate joins with type SEMI/ANTI for the moment.
was (Author: rubenql):
[~hhlai1990], you can create the test using RelBuilder (see
{{EnumerableJoinTest#equiAntiJoin}}, {{EnumerableJoinTest#nonEquiAntiJoin}}).
Unfortunately, I think it is not possible to create tests in SQL, since the SQL
parse does not generate joins with type SEMI/ANTI for the moment.
> Enumerable hash semijoin / antijoin support non-equi join conditions
>
>
> Key: CALCITE-3284
> URL: https://issues.apache.org/jira/browse/CALCITE-3284
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Priority: Major
>
> Calcite should be able to generate enumerable hash semijoin / antijoin with
> non-equi join conditions, as long as there are equi-join condtions, so that
> we can do hash look up.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915539#comment-16915539
]
Ruben Quesada Lopez commented on CALCITE-3284:
--
[~hhlai1990], you can create the test using RelBuilder (see
{{EnumerableJoinTest#equiAntiJoin}}, {{EnumerableJoinTest#nonEquiAntiJoin}}).
Unfortunately, I think it is not possible to create tests in SQL, since the SQL
parse does not generate joins with type SEMI/ANTI for the moment.
> Enumerable hash semijoin / antijoin support non-equi join conditions
>
>
> Key: CALCITE-3284
> URL: https://issues.apache.org/jira/browse/CALCITE-3284
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Priority: Major
>
> Calcite should be able to generate enumerable hash semijoin / antijoin with
> non-equi join conditions, as long as there are equi-join condtions, so that
> we can do hash look up.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3289) Disable test pending fix for Wikipedia format change
[ https://issues.apache.org/jira/browse/CALCITE-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3289: Labels: pull-request-available (was: ) > Disable test pending fix for Wikipedia format change > > > Key: CALCITE-3289 > URL: https://issues.apache.org/jira/browse/CALCITE-3289 > Project: Calcite > Issue Type: Test >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > Attachments: image-2019-08-24-20-35-39-763.png > > > !image-2019-08-24-20-35-39-763.png|width=522,height=112! -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-482) Implement sql and planner hints
[ https://issues.apache.org/jira/browse/CALCITE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915532#comment-16915532 ] Danny Chan commented on CALCITE-482: Thanks, [~hyuan] and [~Chunwei Lei] i have attached the design doc, can you help to review the design ? Maybe we should have a discussion on the doc, or under this issue, either is ok. > Implement sql and planner hints > --- > > Key: CALCITE-482 > URL: https://issues.apache.org/jira/browse/CALCITE-482 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.0.0-incubating >Reporter: Vladimir Sitnikov >Assignee: Danny Chan >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > Query optimizer can never be perfect, so it makes sense to implement hints to > allow user better control the execution. > For instance: "never merge this subquery with others" (`/+ no_merge/`), > "treat those tables as leading ones" (`/*+ leading */`), etc. > Hints would enable predictable performance and the planning time would be > improved as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915531#comment-16915531 ] Lai Zhou commented on CALCITE-3284: --- [~rubenql], Since Calcite can't support `semi join` or `anti join` keywords now, so how to construct a sql to test a semi join with nonEquiConditions? And a anti join with nonEquiConditions? > Enumerable hash semijoin / antijoin support non-equi join conditions > > > Key: CALCITE-3284 > URL: https://issues.apache.org/jira/browse/CALCITE-3284 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Priority: Major > > Calcite should be able to generate enumerable hash semijoin / antijoin with > non-equi join conditions, as long as there are equi-join condtions, so that > we can do hash look up. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Issue Comment Deleted] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lai Zhou updated CALCITE-3284:
--
Comment: was deleted
(was: [~rubenql]， Did Calcite already support semi join/anti join keywords?
I intend to query
{code:java}
SELECT d.deptno, d.name FROM depts d semi join emps e on d.deptno=e.deptno and
d.deptno >10{code}
but the `semi join` is not supported now.
So how to write a case for semi/anti join with nonEquiCondition?)
> Enumerable hash semijoin / antijoin support non-equi join conditions
>
>
> Key: CALCITE-3284
> URL: https://issues.apache.org/jira/browse/CALCITE-3284
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Priority: Major
>
> Calcite should be able to generate enumerable hash semijoin / antijoin with
> non-equi join conditions, as long as there are equi-join condtions, so that
> we can do hash look up.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3284) Enumerable hash semijoin / antijoin support non-equi join conditions
[
https://issues.apache.org/jira/browse/CALCITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915526#comment-16915526
]
Lai Zhou commented on CALCITE-3284:
---
[~rubenql]， Did Calcite already support semi join/anti join keywords?
I intend to query
{code:java}
SELECT d.deptno, d.name FROM depts d semi join emps e on d.deptno=e.deptno and
d.deptno >10{code}
but the `semi join` is not supported now.
So how to write a case for semi/anti join with nonEquiCondition?
> Enumerable hash semijoin / antijoin support non-equi join conditions
>
>
> Key: CALCITE-3284
> URL: https://issues.apache.org/jira/browse/CALCITE-3284
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Priority: Major
>
> Calcite should be able to generate enumerable hash semijoin / antijoin with
> non-equi join conditions, as long as there are equi-join condtions, so that
> we can do hash look up.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3293) Add strcmp function
[ https://issues.apache.org/jira/browse/CALCITE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3293: Labels: pull-request-available (was: ) > Add strcmp function > --- > > Key: CALCITE-3293 > URL: https://issues.apache.org/jira/browse/CALCITE-3293 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > > Add strcmp function. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3293) Add strcmp function
[ https://issues.apache.org/jira/browse/CALCITE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xzh_dz updated CALCITE-3293: Description: Add strcmp function. (was: Add strcmp function) Priority: Minor (was: Major) > Add strcmp function > --- > > Key: CALCITE-3293 > URL: https://issues.apache.org/jira/browse/CALCITE-3293 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Minor > > Add strcmp function. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3293) Add strcmp function
xzh_dz created CALCITE-3293: --- Summary: Add strcmp function Key: CALCITE-3293 URL: https://issues.apache.org/jira/browse/CALCITE-3293 Project: Calcite Issue Type: Improvement Reporter: xzh_dz Add strcmp function -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3290) evaluate in AbstractNode
[ https://issues.apache.org/jira/browse/CALCITE-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xzh_dz updated CALCITE-3290: Description: we could implement the expressions evaluate in AbstractNode directly. > evaluate in AbstractNode > > > Key: CALCITE-3290 > URL: https://issues.apache.org/jira/browse/CALCITE-3290 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > > we could implement the expressions evaluate in AbstractNode directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
