[jira] [Commented] (CALCITE-1430) Error of deciding pagingIdentifiers in select query for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584588#comment-15584588
]
Jiarong Wei commented on CALCITE-1430:
--
Updated! Please review it :)
> Error of deciding pagingIdentifiers in select query for Druid
> -
>
> Key: CALCITE-1430
> URL: https://issues.apache.org/jira/browse/CALCITE-1430
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jiarong Wei
>Assignee: Julian Hyde
>
> When {{segmentGranularity}} is coarse, all data may be fit into just one
> segment. But
> [it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
> should not assume there's only one segment, so {{pagingIdentifiers}} may
> have more than one value.
> PRs:
> https://github.com/apache/calcite/pull/302
> https://github.com/vlsi/calcite-test-dataset/pull/14
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1430) Error of deciding pagingIdentifiers in select query for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiarong Wei updated CALCITE-1430:
-
Description:
When {{segmentGranularity}} is coarse, all data may be fit into just one
segment. But
[it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
should not assume there's only one segment, so {{pagingIdentifiers}} may have
more than one value.
PRs:
https://github.com/apache/calcite/pull/302
https://github.com/vlsi/calcite-test-dataset/pull/14
was:When {{segmentGranularity}} is coarse, all data may be fit into just one
segment. But
[it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
should not assume there's only one segment, so {{pagingIdentifiers}} may have
more than one value.
> Error of deciding pagingIdentifiers in select query for Druid
> -
>
> Key: CALCITE-1430
> URL: https://issues.apache.org/jira/browse/CALCITE-1430
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jiarong Wei
>Assignee: Julian Hyde
>
> When {{segmentGranularity}} is coarse, all data may be fit into just one
> segment. But
> [it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
> should not assume there's only one segment, so {{pagingIdentifiers}} may
> have more than one value.
> PRs:
> https://github.com/apache/calcite/pull/302
> https://github.com/vlsi/calcite-test-dataset/pull/14
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1430) Error of deciding pagingIdentifiers in select query for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiarong Wei updated CALCITE-1430:
-
Description: When {{segmentGranularity}} is coarse, all data may be fit
into just one segment. But
[it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
should not assume there's only one segment, so {{pagingIdentifiers}} may have
more than one value. (was: In
[code|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192],
it presumes {{pagingIdentifiers}} just has one value but actually not.)
> Error of deciding pagingIdentifiers in select query for Druid
> -
>
> Key: CALCITE-1430
> URL: https://issues.apache.org/jira/browse/CALCITE-1430
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jiarong Wei
>Assignee: Julian Hyde
>
> When {{segmentGranularity}} is coarse, all data may be fit into just one
> segment. But
> [it|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L192]
> should not assume there's only one segment, so {{pagingIdentifiers}} may
> have more than one value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1454) Allow custom implementations of SqlConformance
[
https://issues.apache.org/jira/browse/CALCITE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584418#comment-15584418
]
Julian Hyde commented on CALCITE-1454:
--
[~maryannxue], Can you please review my fix in
https://github.com/julianhyde/calcite/tree/1454-custom-conformance?
> Allow custom implementations of SqlConformance
> --
>
> Key: CALCITE-1454
> URL: https://issues.apache.org/jira/browse/CALCITE-1454
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> Allow custom implementations of SqlConformance. This would mean renaming
> {{enum SqlConformance}} to {{enum SqlConformanceEnum}}, and adding a new
> {{interface SqlConformance}}; also {{public abstract class
> SqlAbstractConformance implements SqlConformance}} to protect people who
> write custom implementations of the interface from changes in future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1454) Allow custom implementations of SqlConformance
[
https://issues.apache.org/jira/browse/CALCITE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1454:
-
Fix Version/s: 1.11.0
> Allow custom implementations of SqlConformance
> --
>
> Key: CALCITE-1454
> URL: https://issues.apache.org/jira/browse/CALCITE-1454
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> Allow custom implementations of SqlConformance. This would mean renaming
> {{enum SqlConformance}} to {{enum SqlConformanceEnum}}, and adding a new
> {{interface SqlConformance}}; also {{public abstract class
> SqlAbstractConformance implements SqlConformance}} to protect people who
> write custom implementations of the interface from changes in future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1429) Error of fetching data in select query for Druid
[
https://issues.apache.org/jira/browse/CALCITE-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584413#comment-15584413
]
Jiarong Wei commented on CALCITE-1429:
--
Thanks to the comprehensive tests for Druid adapter, I just need to update some
existing test cases. I've updated the pull request. Please review it :D
> Error of fetching data in select query for Druid
>
>
> Key: CALCITE-1429
> URL: https://issues.apache.org/jira/browse/CALCITE-1429
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jiarong Wei
>Assignee: Julian Hyde
>
> As mentioned in [Druid
> documentation|http://druid.io/docs/0.9.1.1/querying/select-query.html],
> {quote}
> Note that in the second query, an offset is specified and that it is 1
> greater than the largest offset found in the initial results. To return the
> next "page", this offset must be incremented by 1 (should be decremented by 1
> for descending query), with each new query, but with option {{fromNext}}
> enabled, this operation is not needed. When an empty results set is received,
> the very last page has been returned.
> {quote}
> I think Druid adapter
> [presumes|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidQuery.java#L935]
> this feature is turned on but it's not set in
> [code|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidQuery.java#L627].
> Also, {{previousOffset}} may not be reasonable, see
> [DruidQuery|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidQuery.java#L940].
> I think whether we have already fetched all data is decided by the next
> request. If we don't have any data returned on next request, that means
> fetching is done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1454) Allow custom implementations of SqlConformance
Julian Hyde created CALCITE-1454:
Summary: Allow custom implementations of SqlConformance
Key: CALCITE-1454
URL: https://issues.apache.org/jira/browse/CALCITE-1454
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Allow custom implementations of SqlConformance. This would mean renaming {{enum
SqlConformance}} to {{enum SqlConformanceEnum}}, and adding a new {{interface
SqlConformance}}; also {{public abstract class SqlAbstractConformance
implements SqlConformance}} to protect people who write custom implementations
of the interface from changes in future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1426) Support customized star expansion in Table
[
https://issues.apache.org/jira/browse/CALCITE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584382#comment-15584382
]
Maryann Xue commented on CALCITE-1426:
--
Yes, sure. I created a sub-interface CustomExpansionTable and marked it
experimental. Could you please take a look at
https://github.com/apache/calcite/pull/307 again?
> Support customized star expansion in Table
> --
>
> Key: CALCITE-1426
> URL: https://issues.apache.org/jira/browse/CALCITE-1426
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Labels: phoenix
> Fix For: 1.11.0
>
>
> This is to support PHOENIX-3357. Phoenix allows users to define columns in
> arbitrary order regardless of their column families, for example,
> {code}
> CREATE TABLE t
> (a_string varchar not null, cf1.a integer, cf1.b varchar, col1 integer,
> cf2.c varchar, cf2.d integer, col2 integer
> CONSTRAINT pk PRIMARY KEY (a_string))
> {code}
> , in which columns from the same family (i.e., col1 and col2 from the default
> column family) are not necessarily adjacent to each other.
> As a result, when we return row type for a PhoenixTable, we re-order the
> columns in order to fit them into the two-level column structure. This works
> fine in most cases except when:
> 1) "upsert into t ..." would require a different row type even after
> flattening (we do not have flattening so far, still need to implement
> CALCITE-1425).
> 2) select * from t would return a different column order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584271#comment-15584271 ] MinJi Kim commented on CALCITE-1453: [~julianhyde] I will take a look at the patch. > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584271#comment-15584271 ] MinJi Kim edited comment on CALCITE-1453 at 10/18/16 3:08 AM: -- [~julianhyde] and [~kabhwan] I will take a look at the patch. was (Author: minjikim): [~julianhyde] I will take a look at the patch. > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584253#comment-15584253 ] Jungtaek Lim commented on CALCITE-1453: --- I've submitted a patch: https://github.com/apache/calcite/pull/311 Since type information is only available in runtime, I just try to convert all cases to match (Object, Object), and let backup methods care the parameters nicely. During handling parameters which are Number type, I just converted the parameter to BigDecimal so that we can simplify overloading methods, but since there're downsides of the approach I'm OK to find other ways if we think it's not acceptable. > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584240#comment-15584240 ] Julian Hyde commented on CALCITE-1443: -- Yes, the current doc is valid. But someone would have to read the code to find out about the "username" and "password" properties, right? It would be better if all available properties are described in the doc. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1443: -- Fix Version/s: 1.11.0 > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584197#comment-15584197 ] Michael Mior commented on CALCITE-1443: --- I can update to add information on authentication if you prefer, but the current docs are still valid. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Fix For: 1.11.0 > > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584191#comment-15584191 ] Julian Hyde commented on CALCITE-1443: -- Does https://calcite.apache.org/docs/cassandra_adapter.html need an update? > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
[ https://issues.apache.org/jira/browse/CALCITE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584182#comment-15584182 ] Julian Hyde commented on CALCITE-1453: -- [~minjikim], [~jni], You've both done work on ANY. Any ideas? > Support ANY type with binary compare / arithmetic operators > --- > > Key: CALCITE-1453 > URL: https://issues.apache.org/jira/browse/CALCITE-1453 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jungtaek Lim >Assignee: Jungtaek Lim > > Currently Calcite doesn't support applying binary compare / arithmetic > operators with ANY type. One of example is > CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without > explicit casting, it can't find the matching backup method, and complaining > there's no SqlFunctions.eq(Object, int). > There seems to several ways to resolve this, but at least we don't want to > make operator backup method for every combination of types. Needs to avoid > this approach. > When we're addressing this by having backup method, since we don't know the > runtime type for ANY type, even if we succeed to call backup method with > (Object, Object) parameters, two types can be different. This is OK for other > types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1453) Support ANY type with binary compare / arithmetic operators
Jungtaek Lim created CALCITE-1453: - Summary: Support ANY type with binary compare / arithmetic operators Key: CALCITE-1453 URL: https://issues.apache.org/jira/browse/CALCITE-1453 Project: Calcite Issue Type: Improvement Components: core Reporter: Jungtaek Lim Assignee: Jungtaek Lim Currently Calcite doesn't support applying binary compare / arithmetic operators with ANY type. One of example is CollectionTypeTest.testAccessNestedMapWithAnyTypeWithoutCast(). Without explicit casting, it can't find the matching backup method, and complaining there's no SqlFunctions.eq(Object, int). There seems to several ways to resolve this, but at least we don't want to make operator backup method for every combination of types. Needs to avoid this approach. When we're addressing this by having backup method, since we don't know the runtime type for ANY type, even if we succeed to call backup method with (Object, Object) parameters, two types can be different. This is OK for other types, but not Number types. This should be well cared, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-483) Implement correlate expression for enumerable convention
[ https://issues.apache.org/jira/browse/CALCITE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584009#comment-15584009 ] sunjincheng commented on CALCITE-483: - [~julianhyde] Thank you for reminding me. > Implement correlate expression for enumerable convention > > > Key: CALCITE-483 > URL: https://issues.apache.org/jira/browse/CALCITE-483 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Sitnikov >Assignee: Vladimir Sitnikov > Fix For: 1.0.0-incubating > > > Implement LogicalCorrelate and the implementation for enumerable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1449) Support EXCEPT DISTINCT
[
https://issues.apache.org/jira/browse/CALCITE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pengcheng Xiong updated CALCITE-1449:
-
Description:
This will rewrite except distinct as below
{code}
Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
Example: R1 Except All R2
R1 introduce VCol ‘2’, R2 introduce VCol ‘1’
R3 = GB(R1 on all attributes + VCol + count(VCol) as c) union all GB(R2 on all
attributes + VCol + count(VCol) as c)
R4 = GB(R3 on all attributes + sum(c) as a + sum(VCol*c) as b)
Note, now we have m+n=a, 2m+n=b where m is the #row in R1 and n is the #row in
R2 then
m=b-a, n=2a-b, m-n=2b-3a
R5 = Fil (b-a>0 && 2a-b=0)
R6 = select only attributes from R5
{code}
was:
This will rewrite except distinct as below
{code}
Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
Example: R1 Except All R2
R1 introduce VCol ‘2’, R2 introduce VCol ‘1’
R3 = GB(R1 on all attributes + VCol + count(VCol) as c) union all GB(R2 on all
attributes + VCol + count(VCol) as c)
R4 = GB(R3 on all attributes + sum(c) as a + sum(VCol*c) as b)
Note, now we have m+n=a, 2m+n=b where m is the #row in R1 and n is the #row in
R2 then
m=b-a, n=2a-b, m-n=2b-3a
R5 = Fil (b-a>0 && 2a-b=0) R6 = select only attributes from R5
{code}
> Support EXCEPT DISTINCT
> ---
>
> Key: CALCITE-1449
> URL: https://issues.apache.org/jira/browse/CALCITE-1449
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
> This will rewrite except distinct as below
> {code}
> Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
> Example: R1 Except All R2
> R1 introduce VCol ‘2’, R2 introduce VCol ‘1’
> R3 = GB(R1 on all attributes + VCol + count(VCol) as c) union all GB(R2 on
> all attributes + VCol + count(VCol) as c)
> R4 = GB(R3 on all attributes + sum(c) as a + sum(VCol*c) as b)
> Note, now we have m+n=a, 2m+n=b where m is the #row in R1 and n is the #row
> in R2 then
> m=b-a, n=2a-b, m-n=2b-3a
> R5 = Fil (b-a>0 && 2a-b=0)
> R6 = select only attributes from R5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1449) Support EXCEPT DISTINCT
[
https://issues.apache.org/jira/browse/CALCITE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pengcheng Xiong updated CALCITE-1449:
-
Description:
This will rewrite except distinct as below
{code}
Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
Example: R1 Except All R2
R1 introduce VCol ‘2’, R2 introduce VCol ‘1’
R3 = GB(R1 on all attributes + VCol + count(VCol) as c) union all GB(R2 on all
attributes + VCol + count(VCol) as c)
R4 = GB(R3 on all attributes + sum(c) as a + sum(VCol*c) as b)
Note, now we have m+n=a, 2m+n=b where m is the #row in R1 and n is the #row in
R2 then
m=b-a, n=2a-b, m-n=2b-3a
R5 = Fil (b-a>0 && 2a-b=0) R6 = select only attributes from R5
{code}
> Support EXCEPT DISTINCT
> ---
>
> Key: CALCITE-1449
> URL: https://issues.apache.org/jira/browse/CALCITE-1449
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
> This will rewrite except distinct as below
> {code}
> Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
> Example: R1 Except All R2
> R1 introduce VCol ‘2’, R2 introduce VCol ‘1’
> R3 = GB(R1 on all attributes + VCol + count(VCol) as c) union all GB(R2 on
> all attributes + VCol + count(VCol) as c)
> R4 = GB(R3 on all attributes + sum(c) as a + sum(VCol*c) as b)
> Note, now we have m+n=a, 2m+n=b where m is the #row in R1 and n is the #row
> in R2 then
> m=b-a, n=2a-b, m-n=2b-3a
> R5 = Fil (b-a>0 && 2a-b=0) R6 = select only attributes from R5
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1448) Add a rule to merge INTERSECT with its children INTERSECT
[ https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583883#comment-15583883 ] Julian Hyde commented on CALCITE-1448: -- Ah, I see, "intersect merge" is not syntax, it is a planner rule. Makes sense. > Add a rule to merge INTERSECT with its children INTERSECT > - > > Key: CALCITE-1448 > URL: https://issues.apache.org/jira/browse/CALCITE-1448 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > > similar to current unionMergeRule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1452) Support EXCEPT ALL
[ https://issues.apache.org/jira/browse/CALCITE-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1452: - Summary: Support EXCEPT ALL (was: support except all) > Support EXCEPT ALL > -- > > Key: CALCITE-1452 > URL: https://issues.apache.org/jira/browse/CALCITE-1452 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1446) Support INTERSECT, EXCEPT, MINUS, each with DISTINCT, ALL options
[ https://issues.apache.org/jira/browse/CALCITE-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583879#comment-15583879 ] Julian Hyde commented on CALCITE-1446: -- MINUS is simply a synonym for EXCEPT, enabled in certain dialects; it is covered by CALCITE-1125. > Support INTERSECT, EXCEPT, MINUS, each with DISTINCT, ALL options > - > > Key: CALCITE-1446 > URL: https://issues.apache.org/jira/browse/CALCITE-1446 > Project: Calcite > Issue Type: New Feature >Reporter: Pengcheng Xiong >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1450) Support a "replicate_rows" table function
[
https://issues.apache.org/jira/browse/CALCITE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1450:
-
Summary: Support a "replicate_rows" table function (was: support a UDTF
replicate_rows)
> Support a "replicate_rows" table function
> -
>
> Key: CALCITE-1450
> URL: https://issues.apache.org/jira/browse/CALCITE-1450
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Julian Hyde
>
> Add a user-defined table function that has a count column N, and a number of
> other columns, and for each row, produces N copies of that row.
> The purpose of this table function is to implement {{INTERSECT ALL}} and
> {{EXCEPT ALL}}. Observe that if have a table 'five' with 5 rows with the
> value 'x', and a table 'three' with 3 rows with the value 'x', then {{five
> INTERSECT ALL three}} will need to emit {{min(5, 3))}} rows, and {{five
> EXCEPT ALL three}} will emit {{5 - 3}} rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1449) Support EXCEPT DISTINCT
[ https://issues.apache.org/jira/browse/CALCITE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1449: - Summary: Support EXCEPT DISTINCT (was: Support except distinct) > Support EXCEPT DISTINCT > --- > > Key: CALCITE-1449 > URL: https://issues.apache.org/jira/browse/CALCITE-1449 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1446) Support INTERSECT, EXCEPT, MINUS, each with DISTINCT, ALL options
[ https://issues.apache.org/jira/browse/CALCITE-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1446: - Summary: Support INTERSECT, EXCEPT, MINUS, each with DISTINCT, ALL options (was: Support Intersect (distinct/all) Except (distinct/all) Minus (distinct/all)) > Support INTERSECT, EXCEPT, MINUS, each with DISTINCT, ALL options > - > > Key: CALCITE-1446 > URL: https://issues.apache.org/jira/browse/CALCITE-1446 > Project: Calcite > Issue Type: New Feature >Reporter: Pengcheng Xiong >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1451) Support INTERSECT ALL
[ https://issues.apache.org/jira/browse/CALCITE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1451: - Summary: Support INTERSECT ALL (was: support intersect all) > Support INTERSECT ALL > - > > Key: CALCITE-1451 > URL: https://issues.apache.org/jira/browse/CALCITE-1451 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1450) support a UDTF replicate_rows
[
https://issues.apache.org/jira/browse/CALCITE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583861#comment-15583861
]
Julian Hyde commented on CALCITE-1450:
--
It would be useful if {{replicate_rows}} were a relational operator (i.e. a
subclass of {{RelNode}}), not a UDTF. Then we could write rules to push
{{Filter}} and {{Project}} operators through it, and we wouldn't necessarily
have to implement it in Java.
> support a UDTF replicate_rows
> -
>
> Key: CALCITE-1450
> URL: https://issues.apache.org/jira/browse/CALCITE-1450
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Julian Hyde
>
> Add a user-defined table function that has a count column N, and a number of
> other columns, and for each row, produces N copies of that row.
> The purpose of this table function is to implement {{INTERSECT ALL}} and
> {{EXCEPT ALL}}. Observe that if have a table 'five' with 5 rows with the
> value 'x', and a table 'three' with 3 rows with the value 'x', then {{five
> INTERSECT ALL three}} will need to emit {{min(5, 3))}} rows, and {{five
> EXCEPT ALL three}} will emit {{5 - 3}} rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1450) support a UDTF replicate_rows
[
https://issues.apache.org/jira/browse/CALCITE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1450:
-
Description:
Add a user-defined table function that has a count column N, and a number of
other columns, and for each row, produces N copies of that row.
The purpose of this table function is to implement {{INTERSECT ALL}} and
{{EXCEPT ALL}}. Observe that if have a table 'five' with 5 rows with the value
'x', and a table 'three' with 3 rows with the value 'x', then {{five INTERSECT
ALL three}} will need to emit {{min(5, 3))}} rows, and {{five EXCEPT ALL
three}} will emit {{5 - 3}} rows.
was:Add a user-defined table function that has a count column N, and a number
of other columns, and for each row, produces N copies of that row.
> support a UDTF replicate_rows
> -
>
> Key: CALCITE-1450
> URL: https://issues.apache.org/jira/browse/CALCITE-1450
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Julian Hyde
>
> Add a user-defined table function that has a count column N, and a number of
> other columns, and for each row, produces N copies of that row.
> The purpose of this table function is to implement {{INTERSECT ALL}} and
> {{EXCEPT ALL}}. Observe that if have a table 'five' with 5 rows with the
> value 'x', and a table 'three' with 3 rows with the value 'x', then {{five
> INTERSECT ALL three}} will need to emit {{min(5, 3))}} rows, and {{five
> EXCEPT ALL three}} will emit {{5 - 3}} rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1448) Add a rule to merge INTERSECT with its children INTERSECT
[ https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pengcheng Xiong updated CALCITE-1448: - Description: similar to current unionMergeRule. > Add a rule to merge INTERSECT with its children INTERSECT > - > > Key: CALCITE-1448 > URL: https://issues.apache.org/jira/browse/CALCITE-1448 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > > similar to current unionMergeRule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1447) Support INTERSECT DISTINCT
[
https://issues.apache.org/jira/browse/CALCITE-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pengcheng Xiong updated CALCITE-1447:
-
Description:
Interesect distinct will be rewritten as
{code}
Rewrite: (GB-Union All-GB)-GB-FIL-Proj
Example: R1 Intersect All R2
R3 = GB(R1 on all attributes + count() as c) union all GB(R2 on all
attributes + count() as c)
R4 = GB(R3 on all attributes + count(c) as cnt)
R5 = Fil ( cnt == #branch )
R6 = Proj(R5 on all attributes)
{code}
was:
Interesect distinct will be rewritten as
{code}
Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
Example: R1 Intersect All R2
R3 = GB(R1 on all attributes + count() as c) union all GB(R2 on all
attributes + count() as c)
R4 = GB(R3 on all attributes + count(c) as cnt)
R5 = Fil ( cnt == #branch )
R6 = Proj(R5 on all attributes)
{code}
> Support INTERSECT DISTINCT
> --
>
> Key: CALCITE-1447
> URL: https://issues.apache.org/jira/browse/CALCITE-1447
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
> Interesect distinct will be rewritten as
> {code}
> Rewrite: (GB-Union All-GB)-GB-FIL-Proj
> Example: R1 Intersect All R2
> R3 = GB(R1 on all attributes + count() as c) union all GB(R2 on all
> attributes + count() as c)
> R4 = GB(R3 on all attributes + count(c) as cnt)
> R5 = Fil ( cnt == #branch )
> R6 = Proj(R5 on all attributes)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1448) Add a rule to merge INTERSECT with its children INTERSECT
[ https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pengcheng Xiong updated CALCITE-1448: - Summary: Add a rule to merge INTERSECT with its children INTERSECT (was: Support INTERSECT MERGE) > Add a rule to merge INTERSECT with its children INTERSECT > - > > Key: CALCITE-1448 > URL: https://issues.apache.org/jira/browse/CALCITE-1448 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1447) Support INTERSECT DISTINCT
[
https://issues.apache.org/jira/browse/CALCITE-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pengcheng Xiong updated CALCITE-1447:
-
Description:
Interesect distinct will be rewritten as
{code}
Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
Example: R1 Intersect All R2
R3 = GB(R1 on all attributes + count() as c) union all GB(R2 on all
attributes + count() as c)
R4 = GB(R3 on all attributes + count(c) as cnt)
R5 = Fil ( cnt == #branch )
R6 = Proj(R5 on all attributes)
{code}
> Support INTERSECT DISTINCT
> --
>
> Key: CALCITE-1447
> URL: https://issues.apache.org/jira/browse/CALCITE-1447
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
> Interesect distinct will be rewritten as
> {code}
> Rewrite: (GB-Union All-GB)-GB-UDTF (on all attributes)
> Example: R1 Intersect All R2
> R3 = GB(R1 on all attributes + count() as c) union all GB(R2 on all
> attributes + count() as c)
> R4 = GB(R3 on all attributes + count(c) as cnt)
> R5 = Fil ( cnt == #branch )
> R6 = Proj(R5 on all attributes)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1450) support a UDTF replicate_rows
[ https://issues.apache.org/jira/browse/CALCITE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1450: - Description: Add a user-defined table function that has a count column N, and a number of other columns, and for each row, produces N copies of that row. > support a UDTF replicate_rows > - > > Key: CALCITE-1450 > URL: https://issues.apache.org/jira/browse/CALCITE-1450 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Julian Hyde > > Add a user-defined table function that has a count column N, and a number of > other columns, and for each row, produces N copies of that row. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1448) Support INTERSECT MERGE
[ https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1448: - Summary: Support INTERSECT MERGE (was: Support intersect merge) > Support INTERSECT MERGE > --- > > Key: CALCITE-1448 > URL: https://issues.apache.org/jira/browse/CALCITE-1448 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1448) Support intersect merge
[
https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583825#comment-15583825
]
Julian Hyde commented on CALCITE-1448:
--
I'm familiar with {{INTERSECT DISTINCT}} and {{INTERSECT ALL}} - but what is
{{INTERSECT MERGE}}?
> Support intersect merge
> ---
>
> Key: CALCITE-1448
> URL: https://issues.apache.org/jira/browse/CALCITE-1448
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1447) Support INTERSECT DISTINCT
[ https://issues.apache.org/jira/browse/CALCITE-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1447: - Summary: Support INTERSECT DISTINCT (was: Support intersect distinct) > Support INTERSECT DISTINCT > -- > > Key: CALCITE-1447 > URL: https://issues.apache.org/jira/browse/CALCITE-1447 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1447) Support intersect distinct
[
https://issues.apache.org/jira/browse/CALCITE-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583823#comment-15583823
]
Julian Hyde commented on CALCITE-1447:
--
I believe that Calcite already supports {{INTERSECT DISTINCT}}. At least in the
parser.
> Support intersect distinct
> --
>
> Key: CALCITE-1447
> URL: https://issues.apache.org/jira/browse/CALCITE-1447
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Pengcheng Xiong
>Assignee: Pengcheng Xiong
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1452) support except all
Pengcheng Xiong created CALCITE-1452: Summary: support except all Key: CALCITE-1452 URL: https://issues.apache.org/jira/browse/CALCITE-1452 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1449) Support except distinct
[ https://issues.apache.org/jira/browse/CALCITE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pengcheng Xiong reassigned CALCITE-1449: Assignee: Pengcheng Xiong (was: Julian Hyde) > Support except distinct > --- > > Key: CALCITE-1449 > URL: https://issues.apache.org/jira/browse/CALCITE-1449 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1447) Support intersect distinct
[ https://issues.apache.org/jira/browse/CALCITE-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pengcheng Xiong reassigned CALCITE-1447: Assignee: Pengcheng Xiong (was: Julian Hyde) > Support intersect distinct > -- > > Key: CALCITE-1447 > URL: https://issues.apache.org/jira/browse/CALCITE-1447 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1448) Support intersect merge
[ https://issues.apache.org/jira/browse/CALCITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pengcheng Xiong reassigned CALCITE-1448: Assignee: Pengcheng Xiong (was: Julian Hyde) > Support intersect merge > --- > > Key: CALCITE-1448 > URL: https://issues.apache.org/jira/browse/CALCITE-1448 > Project: Calcite > Issue Type: Sub-task >Reporter: Pengcheng Xiong >Assignee: Pengcheng Xiong > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1451) support intersect all
Pengcheng Xiong created CALCITE-1451: Summary: support intersect all Key: CALCITE-1451 URL: https://issues.apache.org/jira/browse/CALCITE-1451 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1449) Support except distinct
Pengcheng Xiong created CALCITE-1449: Summary: Support except distinct Key: CALCITE-1449 URL: https://issues.apache.org/jira/browse/CALCITE-1449 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1450) support a UDTF replicate_rows
Pengcheng Xiong created CALCITE-1450: Summary: support a UDTF replicate_rows Key: CALCITE-1450 URL: https://issues.apache.org/jira/browse/CALCITE-1450 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1448) Support intersect merge
Pengcheng Xiong created CALCITE-1448: Summary: Support intersect merge Key: CALCITE-1448 URL: https://issues.apache.org/jira/browse/CALCITE-1448 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1447) Support intersect distinct
Pengcheng Xiong created CALCITE-1447: Summary: Support intersect distinct Key: CALCITE-1447 URL: https://issues.apache.org/jira/browse/CALCITE-1447 Project: Calcite Issue Type: Sub-task Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1446) Support Intersect (distinct/all) Except (distinct/all) Minus (distinct/all)
Pengcheng Xiong created CALCITE-1446: Summary: Support Intersect (distinct/all) Except (distinct/all) Minus (distinct/all) Key: CALCITE-1446 URL: https://issues.apache.org/jira/browse/CALCITE-1446 Project: Calcite Issue Type: New Feature Reporter: Pengcheng Xiong Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583799#comment-15583799 ] Danilo Chang commented on CALCITE-1443: --- It works for me. Thank you for your help. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1434) User-defined aggregate function that uses a generic interface
[
https://issues.apache.org/jira/browse/CALCITE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1434:
-
Description:
{{AggregateFunctionImpl}} doesn't work if the class implements a generic
interface. We have an interface like below which we want to expose to users for
writing aggregate functions.
{noformat}
public interface UDAF {
A init();
A add(A aggregate, V val);
R result(A aggregate);
}
{noformat}
Internally we create an instance of {{AggregateFunctionImpl}} and register the
Function in {{SchemaPlus}}. However this doesn't work for example if we have an
implementation like below,
{noformat}
public class MySum implements UDAF {
@Override
public Number init() {...}
@Override
public Number add(Number aggregate, Number val) {...}
@Override
public Number result(Number aggregate) {...}
}
{noformat}
We get an Exception "java.lang.RuntimeException: In user-defined aggregate
class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
(the return type of the 'init' method)"
This happens because the ReflectiveFunctionBase.findMethod is trying to look
for a method name "init" and it get a method with a different signature (that
returns Object) instead of the actual method defined in MySum. This happens to
be a 'bridge' method inserted by java.
In findMethod, the bridge methods can be skipped while looking for the method
by name.
was:
We have an interface like below which we want to expose to users for writing
aggregate functions.
{noformat}
public interface UDAF {
A init();
A add(A aggregate, V val);
R result(A aggregate);
}
{noformat}
Internally we create an instance of AggregateFunctionImpl and register the
Function in SchemaPlus. However this doesn't work for example if we have an
implementation like below,
{noformat}
public class MySum implements UDAF {
@Override
public Number init() {...}
@Override
public Number add(Number aggregate, Number val) {...}
@Override
public Number result(Number aggregate) {...}
}
{noformat}
We get an Exception "java.lang.RuntimeException: In user-defined aggregate
class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
(the return type of the 'init' method)"
This happens because the ReflectiveFunctionBase.findMethod is trying to look
for a method name "init" and it get a method with a different signature (that
returns Object) instead of the actual method defined in MySum. This happens to
be a 'bridge' method inserted by java.
In findMethod, the bridge methods can be skipped while looking for the method
by name.
> User-defined aggregate function that uses a generic interface
> -
>
> Key: CALCITE-1434
> URL: https://issues.apache.org/jira/browse/CALCITE-1434
> Project: Calcite
> Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> {{AggregateFunctionImpl}} doesn't work if the class implements a generic
> interface. We have an interface like below which we want to expose to users
> for writing aggregate functions.
> {noformat}
> public interface UDAF {
> A init();
> A add(A aggregate, V val);
> R result(A aggregate);
> }
> {noformat}
> Internally we create an instance of {{AggregateFunctionImpl}} and register
> the Function in {{SchemaPlus}}. However this doesn't work for example if we
> have an implementation like below,
> {noformat}
> public class MySum implements UDAF {
> @Override
> public Number init() {...}
> @Override
> public Number add(Number aggregate, Number val) {...}
> @Override
> public Number result(Number aggregate) {...}
> }
> {noformat}
> We get an Exception "java.lang.RuntimeException: In user-defined aggregate
> class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
> (the return type of the 'init' method)"
> This happens because the ReflectiveFunctionBase.findMethod is trying to look
> for a method name "init" and it get a method with a different signature (that
> returns Object) instead of the actual method defined in MySum. This happens
> to be a 'bridge' method inserted by java.
> In findMethod, the bridge methods can be skipped while looking for the method
> by name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1434) User-defined aggregate function that uses a generic interface
[
https://issues.apache.org/jira/browse/CALCITE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1434:
-
Summary: User-defined aggregate function that uses a generic interface
(was: AggregateFunctionImpl doesnt work if the class implements a generic
interface)
> User-defined aggregate function that uses a generic interface
> -
>
> Key: CALCITE-1434
> URL: https://issues.apache.org/jira/browse/CALCITE-1434
> Project: Calcite
> Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> We have an interface like below which we want to expose to users for writing
> aggregate functions.
> {noformat}
> public interface UDAF {
> A init();
> A add(A aggregate, V val);
> R result(A aggregate);
> }
> {noformat}
> Internally we create an instance of AggregateFunctionImpl and register the
> Function in SchemaPlus. However this doesn't work for example if we have an
> implementation like below,
> {noformat}
> public class MySum implements UDAF {
> @Override
> public Number init() {...}
> @Override
> public Number add(Number aggregate, Number val) {...}
> @Override
> public Number result(Number aggregate) {...}
> }
> {noformat}
> We get an Exception "java.lang.RuntimeException: In user-defined aggregate
> class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
> (the return type of the 'init' method)"
> This happens because the ReflectiveFunctionBase.findMethod is trying to look
> for a method name "init" and it get a method with a different signature (that
> returns Object) instead of the actual method defined in MySum. This happens
> to be a 'bridge' method inserted by java.
> In findMethod, the bridge methods can be skipped while looking for the method
> by name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1434) AggregateFunctionImpl doesnt work if the class implements a generic interface
[
https://issues.apache.org/jira/browse/CALCITE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1434.
--
Resolution: Fixed
Fix Version/s: 1.11.0
> AggregateFunctionImpl doesnt work if the class implements a generic interface
> -
>
> Key: CALCITE-1434
> URL: https://issues.apache.org/jira/browse/CALCITE-1434
> Project: Calcite
> Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Julian Hyde
> Fix For: 1.11.0
>
>
> We have an interface like below which we want to expose to users for writing
> aggregate functions.
> {noformat}
> public interface UDAF {
> A init();
> A add(A aggregate, V val);
> R result(A aggregate);
> }
> {noformat}
> Internally we create an instance of AggregateFunctionImpl and register the
> Function in SchemaPlus. However this doesn't work for example if we have an
> implementation like below,
> {noformat}
> public class MySum implements UDAF {
> @Override
> public Number init() {...}
> @Override
> public Number add(Number aggregate, Number val) {...}
> @Override
> public Number result(Number aggregate) {...}
> }
> {noformat}
> We get an Exception "java.lang.RuntimeException: In user-defined aggregate
> class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
> (the return type of the 'init' method)"
> This happens because the ReflectiveFunctionBase.findMethod is trying to look
> for a method name "init" and it get a method with a different signature (that
> returns Object) instead of the actual method defined in MySum. This happens
> to be a 'bridge' method inserted by java.
> In findMethod, the bridge methods can be skipped while looking for the method
> by name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1442) SqlIntervalQualifer#getFractionalSecondPrecisionPreservingDefault() returns the wrong field
[
https://issues.apache.org/jira/browse/CALCITE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1442.
--
Resolution: Fixed
Fix Version/s: 1.11.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/25a7d938; thanks
for the PR, [~laurentgo]!
> SqlIntervalQualifer#getFractionalSecondPrecisionPreservingDefault() returns
> the wrong field
> ---
>
> Key: CALCITE-1442
> URL: https://issues.apache.org/jira/browse/CALCITE-1442
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.11.0
>
>
> Unless I'm wrong, I believe
> {{SqlIntervalQualifer#getFractionalSecondPrecisionPreservingDefault()}}
> returns the wrong field:
> {code:java}
> public int getFractionalSecondPrecision(RelDataTypeSystem typeSystem) {
> if (fractionalSecondPrecision == RelDataType.PRECISION_NOT_SPECIFIED) {
> return typeName().getDefaultScale();
> } else {
> return fractionalSecondPrecision;
> }
> }
> public int getFractionalSecondPrecisionPreservingDefault() {
> if (useDefaultFractionalSecondPrecision()) {
> return RelDataType.PRECISION_NOT_SPECIFIED;
> } else {
> return startPrecision;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1442) Interval fractional second precision returns wrong value
[
https://issues.apache.org/jira/browse/CALCITE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1442:
-
Summary: Interval fractional second precision returns wrong value (was:
SqlIntervalQualifer#getFractionalSecondPrecisionPreservingDefault() returns the
wrong field)
> Interval fractional second precision returns wrong value
>
>
> Key: CALCITE-1442
> URL: https://issues.apache.org/jira/browse/CALCITE-1442
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.11.0
>
>
> Unless I'm wrong, I believe
> {{SqlIntervalQualifer#getFractionalSecondPrecisionPreservingDefault()}}
> returns the wrong field:
> {code:java}
> public int getFractionalSecondPrecision(RelDataTypeSystem typeSystem) {
> if (fractionalSecondPrecision == RelDataType.PRECISION_NOT_SPECIFIED) {
> return typeName().getDefaultScale();
> } else {
> return fractionalSecondPrecision;
> }
> }
> public int getFractionalSecondPrecisionPreservingDefault() {
> if (useDefaultFractionalSecondPrecision()) {
> return RelDataType.PRECISION_NOT_SPECIFIED;
> } else {
> return startPrecision;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1434) AggregateFunctionImpl doesnt work if the class implements a generic interface
[
https://issues.apache.org/jira/browse/CALCITE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583783#comment-15583783
]
Julian Hyde commented on CALCITE-1434:
--
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/55ba6b58.
[~arunmahadevan], thanks for the PR!
> AggregateFunctionImpl doesnt work if the class implements a generic interface
> -
>
> Key: CALCITE-1434
> URL: https://issues.apache.org/jira/browse/CALCITE-1434
> Project: Calcite
> Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Julian Hyde
>
> We have an interface like below which we want to expose to users for writing
> aggregate functions.
> {noformat}
> public interface UDAF {
> A init();
> A add(A aggregate, V val);
> R result(A aggregate);
> }
> {noformat}
> Internally we create an instance of AggregateFunctionImpl and register the
> Function in SchemaPlus. However this doesn't work for example if we have an
> implementation like below,
> {noformat}
> public class MySum implements UDAF {
> @Override
> public Number init() {...}
> @Override
> public Number add(Number aggregate, Number val) {...}
> @Override
> public Number result(Number aggregate) {...}
> }
> {noformat}
> We get an Exception "java.lang.RuntimeException: In user-defined aggregate
> class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
> (the return type of the 'init' method)"
> This happens because the ReflectiveFunctionBase.findMethod is trying to look
> for a method name "init" and it get a method with a different signature (that
> returns Object) instead of the actual method defined in MySum. This happens
> to be a 'bridge' method inserted by java.
> In findMethod, the bridge methods can be skipped while looking for the method
> by name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583727#comment-15583727
]
Laurent Goujon commented on CALCITE-1444:
-
sounds good. I still need to add the regular interval types to the parser I
guess (or the query won't be valid).
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583723#comment-15583723
]
Laurent Goujon commented on CALCITE-1444:
-
I missed your update, thanks for the clarification though.
Looking at {{TimeUnitRange}} it's an avatica utility class, is it still okay to
use in calcite-core?
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583715#comment-15583715
]
Julian Hyde commented on CALCITE-1444:
--
I think it's OK. When we unparse it has to produce a valid query, and a query
that has the same effect, but it doesn't have to be same query.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583704#comment-15583704
]
Laurent Goujon commented on CALCITE-1444:
-
I just updated the pull request to address some of the comments. One question I
have is regarding unparsing the query: it currently returns the legacy type
identifier instead of the SQL_ ones, and I wonder if I should address this, or
if this is okay...
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583693#comment-15583693
]
Julian Hyde edited comment on CALCITE-1444 at 10/17/16 10:27 PM:
-
No, {{JdbcOdbcType}} and {{OdbcIntervalType}} should still return
{{SqlDataTypeSpec}}. You can just make their internal logic more concise. Note
that the pattern 'typeName = new SqlIdentifier(SqlTypeName.xxx.name(), pos);'
occurs many times, so refactor it by introducing an internal function that
returns a SqlTypeName.
In OdbcIntervalType, introduce an internal function that returns a
TimeUnitRange. It has a start and an end TimeUnit.
The logic will be the same as what you've written, but fewer lines of code to
maintain.
{quote}I guess I missed updating the tables for the scalar functions{quote}
Yes, you missed https://calcite.apache.org/docs/reference.html#system
was (Author: julianhyde):
No, {{JdbcOdbcType}} and {{OdbcIntervalType}} should still return
{{SqlDataTypeSpec}}. You can just make their internal logic more concise. Note
that the pattern 'typeName = new SqlIdentifier(SqlTypeName.xxx.name(), pos);'
occurs many times, so refactor it by introducing an internal function that
returns a SqlTypeName.
In OdbcIntervalType, introduce an internal function that returns a
TimeUnitRange. It has a start and an end TimeUnit.
The logic will be the same as what you've written, but fewer lines of code to
maintain.
> I guess I missed updating the tables for the scalar functions
Yes, you missed https://calcite.apache.org/docs/reference.html#system
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583693#comment-15583693
]
Julian Hyde commented on CALCITE-1444:
--
No, {{JdbcOdbcType}} and {{OdbcIntervalType}} should still return
{{SqlDataTypeSpec}}. You can just make their internal logic more concise. Note
that the pattern 'typeName = new SqlIdentifier(SqlTypeName.xxx.name(), pos);'
occurs many times, so refactor it by introducing an internal function that
returns a SqlTypeName.
In OdbcIntervalType, introduce an internal function that returns a
TimeUnitRange. It has a start and an end TimeUnit.
The logic will be the same as what you've written, but fewer lines of code to
maintain.
> I guess I missed updating the tables for the scalar functions
Yes, you missed https://calcite.apache.org/docs/reference.html#system
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583612#comment-15583612
]
Laurent Goujon commented on CALCITE-1444:
-
{quote}
In Parser.jj, you would reduce redundancy by assigning to a SqlTypeName
variable rather than a SqlIdentifier. Make it more compact, like the
TimestampInterval function.
{quote}
do you mean just returning {{SqlTypeName}} for {{JdbcOdbcType}} and
{{OdbcIntervalType}}. It seems there's no function to create a SqlDataTypeSpec
out of a typename, nor can you use an interval type with {{SqlDataTypeSpec}},
so I still end up having two functions (one for non-interval types, and one for
interval types), and I still need to create an instance of {{SqlDataTypeSpec}}
out of the type name. Did I miss something?
{quote}
Please add one or two tests to SqlParserTest. (SqlOperatorTest is fine, but
it's more of a system test.) Also add one or two negative tests.
{quote}
I'll do.
{quote}
Also please modify REFERENCE.md.
{quote}
I guess I missed updating the tables for the scalar functions
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1445) Calls to NEXT VALUE FOR sequence should return different results
[
https://issues.apache.org/jira/browse/CALCITE-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583509#comment-15583509
]
Julian Hyde commented on CALCITE-1445:
--
Test case: https://github.com/julianhyde/calcite/tree/1445-sequence-next-value
> Calls to NEXT VALUE FOR sequence should return different results
>
>
> Key: CALCITE-1445
> URL: https://issues.apache.org/jira/browse/CALCITE-1445
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Calls to NEXT VALUE FOR sequence should return different results. Currently,
> the calls are combined by the planner, so the results are the same.
> {code}
> select *
> from (
> select *
> from (values 1, 2) as t (c)
> where next value for "my_seq" > 10)
> where next value for "my_seq" < 10;
> {code}
> yields plan
> {code}
> EnumerableCalc(expr#0=[{inputs}], expr#1=['"my_seq"'],
> expr#2=[NEXT_VALUE($t1)], expr#3=[10], expr#4=[>($t2, $t3)], expr#5=[<($t2,
> $t3)], expr#6=[AND($t4, $t5)], EXPR$0=[$t0], $condition=[$t6])
> EnumerableValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> [~jamestaylor], [~maryannxue], Is this the behavior you would like/expect in
> Phoenix?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1445) Calls to NEXT VALUE FOR sequence should return different results
Julian Hyde created CALCITE-1445:
Summary: Calls to NEXT VALUE FOR sequence should return different
results
Key: CALCITE-1445
URL: https://issues.apache.org/jira/browse/CALCITE-1445
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Calls to NEXT VALUE FOR sequence should return different results. Currently,
the calls are combined by the planner, so the results are the same.
{code}
select *
from (
select *
from (values 1, 2) as t (c)
where next value for "my_seq" > 10)
where next value for "my_seq" < 10;
{code}
yields plan
{code}
EnumerableCalc(expr#0=[{inputs}], expr#1=['"my_seq"'],
expr#2=[NEXT_VALUE($t1)], expr#3=[10], expr#4=[>($t2, $t3)], expr#5=[<($t2,
$t3)], expr#6=[AND($t4, $t5)], EXPR$0=[$t0], $condition=[$t6])
EnumerableValues(tuples=[[{ 1 }, { 2 }]])
{code}
[~jamestaylor], [~maryannxue], Is this the behavior you would like/expect in
Phoenix?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1426) Support customized star expansion in Table
[
https://issues.apache.org/jira/browse/CALCITE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583438#comment-15583438
]
Julian Hyde commented on CALCITE-1426:
--
I agree, returning lists of strings is best for now. But please mark the
interface experimental, so we can change our minds.
> Support customized star expansion in Table
> --
>
> Key: CALCITE-1426
> URL: https://issues.apache.org/jira/browse/CALCITE-1426
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Labels: phoenix
> Fix For: 1.11.0
>
>
> This is to support PHOENIX-3357. Phoenix allows users to define columns in
> arbitrary order regardless of their column families, for example,
> {code}
> CREATE TABLE t
> (a_string varchar not null, cf1.a integer, cf1.b varchar, col1 integer,
> cf2.c varchar, cf2.d integer, col2 integer
> CONSTRAINT pk PRIMARY KEY (a_string))
> {code}
> , in which columns from the same family (i.e., col1 and col2 from the default
> column family) are not necessarily adjacent to each other.
> As a result, when we return row type for a PhoenixTable, we re-order the
> columns in order to fit them into the two-level column structure. This works
> fine in most cases except when:
> 1) "upsert into t ..." would require a different row type even after
> flattening (we do not have flattening so far, still need to implement
> CALCITE-1425).
> 2) select * from t would return a different column order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583403#comment-15583403
]
Julian Hyde commented on CALCITE-1444:
--
In Parser.jj, you would reduce redundancy by assigning to a SqlTypeName
variable rather than a SqlIdentifier. Make it more compact, like the
{{TimestampInterval}} function.
Please add one or two tests to SqlParserTest. (SqlOperatorTest is fine, but
it's more of a system test.) Also add one or two negative tests.
Also please modify REFERENCE.md.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583368#comment-15583368
]
Laurent Goujon commented on CALCITE-1444:
-
Proposed change: https://github.com/apache/calcite/pull/310
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583367#comment-15583367
]
Julian Hyde edited comment on CALCITE-1444 at 10/17/16 8:36 PM:
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the {{fn ...}} syntax, they should be able to coexist.
was (Author: julianhyde):
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the {{ \{fn ... \} }} syntax, they should be able to coexist.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583367#comment-15583367
]
Julian Hyde edited comment on CALCITE-1444 at 10/17/16 8:36 PM:
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the {{ \{fn ... \} }} syntax, they should be able to coexist.
was (Author: julianhyde):
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the "{fn ...}" syntax, they should be able to coexist.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583367#comment-15583367
]
Julian Hyde edited comment on CALCITE-1444 at 10/17/16 8:35 PM:
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the "{fn ...}" syntax, they should be able to coexist.
was (Author: julianhyde):
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the {{ {fn ...} }} syntax, they should be able to coexist.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1444) Add support for CONVERT scalar function
[
https://issues.apache.org/jira/browse/CALCITE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583367#comment-15583367
]
Julian Hyde commented on CALCITE-1444:
--
This would be great.
Note that the SQL standard has a {{CONVERT}} function (see CALCITE-111) which
has a different purpose (it relates to character sets). Since it is specified
without the {{ {fn ...} }} syntax, they should be able to coexist.
> Add support for CONVERT scalar function
> ---
>
> Key: CALCITE-1444
> URL: https://issues.apache.org/jira/browse/CALCITE-1444
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Laurent Goujon
>Assignee: Julian Hyde
>
> Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
> equivalent of the {{CAST}} function.
> In order for JDBC and ODBC drivers to expose support for this function,
> calcite should support parsing it, and converting it into a {{CAST}}
> expression (currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1444) Add support for CONVERT scalar function
Laurent Goujon created CALCITE-1444:
---
Summary: Add support for CONVERT scalar function
Key: CALCITE-1444
URL: https://issues.apache.org/jira/browse/CALCITE-1444
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Laurent Goujon
Assignee: Julian Hyde
Both ODBC and JDBC spec mention a {{CONVERT}} scalar function, which is the
equivalent of the {{CAST}} function.
In order for JDBC and ODBC drivers to expose support for this function, calcite
should support parsing it, and converting it into a {{CAST}} expression
(currently, it doesn't unlike some other scalar functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1389) Add rule to perform rewriting of queries using materialized views with joins
[ https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582936#comment-15582936 ] Julian Hyde commented on CALCITE-1389: -- I'm happy for these changes to go in. But I'd like to have a sense for where the effort is going - and where it fits with related efforts. How would you feel about creating a page in our documentation about materialized views? It would cover regular materializations (with their general-purpose matching algorithm), lattices (specialized for SPJA), planning secondary indexes (as [~maryannxue] has done in Phoenix), view recommendations, and life cycle issues (how do we invalidate materialized views? how to add the necessary hooks so that they appear in the schema). We could discuss which query patterns each kind of MV can handle; and compare with MVs in other systems such as Cassandra and Druid; and list some of the possible future directions. It would help our users figure out which are the best pieces of our (complicated) framework to use. > Add rule to perform rewriting of queries using materialized views with joins > > > Key: CALCITE-1389 > URL: https://issues.apache.org/jira/browse/CALCITE-1389 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior > Fix For: 1.11.0 > > > I've been looking into implementing the approach from the following paper. > It's very nicely written and easy to follow. It also doesn't require trying > different join permutations. I'm starting with several additional > restrictions (only equijoins, no aggregations, etc.) > ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf > Thanks to [~jcamachorodriguez] for his help in sorting out some issues with > the rule so far. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582844#comment-15582844 ] Michael Mior commented on CALCITE-1443: --- Thanks for the patch! I'd prefer to keep backwards compatibility, but check out [this branch|https://github.com/michaelmior/calcite/tree/1443-cassandra-auth] and see if it works for you. If it does I'll merge this soon and it will be in the next release of Calcite. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior reassigned CALCITE-1443: - Assignee: Michael Mior > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Assignee: Michael Mior >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danilo Chang updated CALCITE-1443: -- Description: Calcite Cassandra adapter does not support Cassandra authenticator option is set to PasswordAuthenticator case. Cassandra adapter operand now only support host and keyspace option, I think need add username and password option. was: Calcite Cassandra adapter does not support Cassandra authenticator option is set to PasswordAuthenticator case. Cassandra adapter operand new only support host and keyspace option, I think need add username and password option. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand now only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danilo Chang updated CALCITE-1443: -- Flags: Patch (was: Important) > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand new only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1443) Add authentication support for Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danilo Chang updated CALCITE-1443: -- Attachment: cass_auth.patch In the attachment, I add authentication support for Cassandra adapter. However, I need modify CassandraSchema class interface and operand option need add username and password (so it is an INCOMPATIBILITY change). I don't konw it is OK or not. So I create this item and hope that have better solution for authentication support for Cassandra adapter. > Add authentication support for Cassandra adapter > > > Key: CALCITE-1443 > URL: https://issues.apache.org/jira/browse/CALCITE-1443 > Project: Calcite > Issue Type: Improvement > Components: cassandra > Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra > adapter >Reporter: Danilo Chang >Priority: Minor > Attachments: cass_auth.patch > > > Calcite Cassandra adapter does not support Cassandra authenticator option is > set to PasswordAuthenticator case. > Cassandra adapter operand new only support host and keyspace option, I think > need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1443) Add authentication support for Cassandra adapter
Danilo Chang created CALCITE-1443: - Summary: Add authentication support for Cassandra adapter Key: CALCITE-1443 URL: https://issues.apache.org/jira/browse/CALCITE-1443 Project: Calcite Issue Type: Improvement Components: cassandra Environment: Test on Apache Cassandra 3.9 and Calcite Cassandra adapter Reporter: Danilo Chang Priority: Minor Calcite Cassandra adapter does not support Cassandra authenticator option is set to PasswordAuthenticator case. Cassandra adapter operand new only support host and keyspace option, I think need add username and password option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1434) AggregateFunctionImpl doesnt work if the class implements a generic interface
[
https://issues.apache.org/jira/browse/CALCITE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582636#comment-15582636
]
Julian Hyde commented on CALCITE-1434:
--
I'll take a look.
> AggregateFunctionImpl doesnt work if the class implements a generic interface
> -
>
> Key: CALCITE-1434
> URL: https://issues.apache.org/jira/browse/CALCITE-1434
> Project: Calcite
> Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Julian Hyde
>
> We have an interface like below which we want to expose to users for writing
> aggregate functions.
> {noformat}
> public interface UDAF {
> A init();
> A add(A aggregate, V val);
> R result(A aggregate);
> }
> {noformat}
> Internally we create an instance of AggregateFunctionImpl and register the
> Function in SchemaPlus. However this doesn't work for example if we have an
> implementation like below,
> {noformat}
> public class MySum implements UDAF {
> @Override
> public Number init() {...}
> @Override
> public Number add(Number aggregate, Number val) {...}
> @Override
> public Number result(Number aggregate) {...}
> }
> {noformat}
> We get an Exception "java.lang.RuntimeException: In user-defined aggregate
> class 'x.y.z.$MySum', first parameter to 'add' method must be the accumulator
> (the return type of the 'init' method)"
> This happens because the ReflectiveFunctionBase.findMethod is trying to look
> for a method name "init" and it get a method with a different signature (that
> returns Object) instead of the actual method defined in MySum. This happens
> to be a 'bridge' method inserted by java.
> In findMethod, the bridge methods can be skipped while looking for the method
> by name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-483) Implement correlate expression for enumerable convention
[ https://issues.apache.org/jira/browse/CALCITE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582610#comment-15582610 ] Julian Hyde commented on CALCITE-483: - @sunjincheng, Let's not start a conversation on an issue that has been closed for 2 years. Feel free to ask your question on the dev list. > Implement correlate expression for enumerable convention > > > Key: CALCITE-483 > URL: https://issues.apache.org/jira/browse/CALCITE-483 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Sitnikov >Assignee: Vladimir Sitnikov > Fix For: 1.0.0-incubating > > > Implement LogicalCorrelate and the implementation for enumerable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
