[jira] [Commented] (CALCITE-1953) Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable inputs
[
https://issues.apache.org/jira/browse/CALCITE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144302#comment-16144302
]
MinJi Kim commented on CALCITE-1953:
[~julianhyde] I made changes to the PR according to your comments. I modified
the SqlKind.negate() and negateNullSafe() so that we negate the operators
properly. Thanks again for reviewing!
It looks like the change to ReduceExpressionsRule is no longer needed (fixed in
[CALCITE-1397] ClassCastException in FilterReduceExpressionsRule, 0a1a190).
https://github.com/apache/calcite/pull/521
> Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable
> inputs
> ---
>
> Key: CALCITE-1953
> URL: https://issues.apache.org/jira/browse/CALCITE-1953
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexSimplify, when simplifying NOT(), we negate the input expression. But
> for IS_FALSE/IS_TRUE/IS_NOT_FALSE/IS_NOT_TRUE this cannot be just negated if
> the input is nullable.
> {code}
> IS_FALSE(null) = false
> IS_TRUE(null) = false
> NOT(IS_FALSE(null)) = true != IS_TRUE(null)
> IS_NOT_FALSE(null) = true
> IS_NOT_TRUE(null) = true
> NOT(IS_NOT_FALSE(null)) = false != IS_NOT_TRUE(null)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1953) Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable inputs
[
https://issues.apache.org/jira/browse/CALCITE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144302#comment-16144302
]
MinJi Kim edited comment on CALCITE-1953 at 8/28/17 8:31 PM:
-
[~julianhyde] I made changes to the PR according to your comments. I modified
the SqlKind.negate() and negateNullSafe() so that we negate the operators
properly. Thanks again for reviewing!
It looks like the change to ReduceExpressionsRule is no longer needed (fixed in
[CALCITE-1397], 0a1a190).
https://github.com/apache/calcite/pull/521
was (Author: minjikim):
[~julianhyde] I made changes to the PR according to your comments. I modified
the SqlKind.negate() and negateNullSafe() so that we negate the operators
properly. Thanks again for reviewing!
It looks like the change to ReduceExpressionsRule is no longer needed (fixed in
[CALCITE-1397] ClassCastException in FilterReduceExpressionsRule, 0a1a190).
https://github.com/apache/calcite/pull/521
> Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable
> inputs
> ---
>
> Key: CALCITE-1953
> URL: https://issues.apache.org/jira/browse/CALCITE-1953
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexSimplify, when simplifying NOT(), we negate the input expression. But
> for IS_FALSE/IS_TRUE/IS_NOT_FALSE/IS_NOT_TRUE this cannot be just negated if
> the input is nullable.
> {code}
> IS_FALSE(null) = false
> IS_TRUE(null) = false
> NOT(IS_FALSE(null)) = true != IS_TRUE(null)
> IS_NOT_FALSE(null) = true
> IS_NOT_TRUE(null) = true
> NOT(IS_NOT_FALSE(null)) = false != IS_NOT_TRUE(null)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1953) Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable inputs
[
https://issues.apache.org/jira/browse/CALCITE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143330#comment-16143330
]
MinJi Kim commented on CALCITE-1953:
[~julianhyde] I think your suggestion for IS_NOT_TRUE makes sense to me, and it
would make things much cleaner. I will update the PR.
|| ||true||false||null||
|IS_TRUE|true|false|false|
|IS_NOT_TRUE|false|true|true|
|IS_FALSE|false|true|false|
|IS_NOT_FALSE|true|false|true|
> Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable
> inputs
> ---
>
> Key: CALCITE-1953
> URL: https://issues.apache.org/jira/browse/CALCITE-1953
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexSimplify, when simplifying NOT(), we negate the input expression. But
> for IS_FALSE/IS_TRUE/IS_NOT_FALSE/IS_NOT_TRUE this cannot be just negated if
> the input is nullable.
> {code}
> IS_FALSE(null) = false
> IS_TRUE(null) = false
> NOT(IS_FALSE(null)) = true != IS_TRUE(null)
> IS_NOT_FALSE(null) = true
> IS_NOT_TRUE(null) = true
> NOT(IS_NOT_FALSE(null)) = false != IS_NOT_TRUE(null)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1945) Allow custom return types for AVG/VARIANCE/STDDEV/COVAR
[ https://issues.apache.org/jira/browse/CALCITE-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143253#comment-16143253 ] MinJi Kim commented on CALCITE-1945: Thank you for the review, [~julianhyde]! I am sorry for the delay in getting back with an updated patch. I am still traveling, but now do have some time to get back to this. I have updated the PR, and addressed the comments you gave. RexBuilder.ensureType() really do make the code nicer. Thanks for the pointer! https://github.com/apache/calcite/pull/518 > Allow custom return types for AVG/VARIANCE/STDDEV/COVAR > --- > > Key: CALCITE-1945 > URL: https://issues.apache.org/jira/browse/CALCITE-1945 > Project: Calcite > Issue Type: Bug >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, return types of AVG() is the input type. So, if the input is > INT/BIGINT type, AVG() is always truncated. Depending on the database, some > database follow this behavior while others (e.g. Oracle/MySQL/etc.) do not > and return floating point values for AVG(). > Similar for other functions mentioned here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1956) Allow MultiJoin to contain multiple FULL joins
[ https://issues.apache.org/jira/browse/CALCITE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131673#comment-16131673 ] MinJi Kim commented on CALCITE-1956: I am actually curious if this was intentionally disallowed (e.g. combining multiple full outer joins in a multi join), and if so, what the reason might have been. Here are some small changes I made to these rules to allow full outer joins in a multi join. Thank you for taking a look. https://github.com/apache/calcite/pull/523 > Allow MultiJoin to contain multiple FULL joins > -- > > Key: CALCITE-1956 > URL: https://issues.apache.org/jira/browse/CALCITE-1956 > Project: Calcite > Issue Type: Bug >Reporter: MinJi Kim >Assignee: Julian Hyde > > JoniToMultiJoinRule collapses multiple INNER joins into a single MultiJoin. > I was wondering if all the joins are full outer joins, couldn't we use the > same logic to allow MultiJoins to contains multiple FULL joins? This would > allow LoptOptimizeJoinRule to re-order full outer joins, just like inner > joins. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1956) Allow MultiJoin to contain multiple FULL joins
MinJi Kim created CALCITE-1956: -- Summary: Allow MultiJoin to contain multiple FULL joins Key: CALCITE-1956 URL: https://issues.apache.org/jira/browse/CALCITE-1956 Project: Calcite Issue Type: Bug Reporter: MinJi Kim Assignee: Julian Hyde JoniToMultiJoinRule collapses multiple INNER joins into a single MultiJoin. I was wondering if all the joins are full outer joins, couldn't we use the same logic to allow MultiJoins to contains multiple FULL joins? This would allow LoptOptimizeJoinRule to re-order full outer joins, just like inner joins. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1954) SqlValidator need to maintain forceNullable across joins and renaming
[
https://issues.apache.org/jira/browse/CALCITE-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131439#comment-16131439
]
MinJi Kim commented on CALCITE-1954:
A small patch, but would appreciate another set of eyes to review this. Thank
you!
https://github.com/apache/calcite/pull/522
> SqlValidator need to maintain forceNullable across joins and renaming
> -
>
> Key: CALCITE-1954
> URL: https://issues.apache.org/jira/browse/CALCITE-1954
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In the following query below, SqlValidator return rowtype with the second
> column as NOT NULL. Since this is a left outer join, it should be nullable.
> {code}
> select * from
> (select row_number() over (order by sal) from emp) as emp1(r1)
> left outer join
> (select dense_rank() over(order by sal) from emp) as emp2(r2)
> on (emp1.r1 = emp2.r2)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1954) SqlValidator need to maintain forceNullable across joins and renaming
MinJi Kim created CALCITE-1954:
--
Summary: SqlValidator need to maintain forceNullable across joins
and renaming
Key: CALCITE-1954
URL: https://issues.apache.org/jira/browse/CALCITE-1954
Project: Calcite
Issue Type: Bug
Reporter: MinJi Kim
Assignee: Julian Hyde
In the following query below, SqlValidator return rowtype with the second
column as NOT NULL. Since this is a left outer join, it should be nullable.
{code}
select * from
(select row_number() over (order by sal) from emp) as emp1(r1)
left outer join
(select dense_rank() over(order by sal) from emp) as emp2(r2)
on (emp1.r1 = emp2.r2)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1953) Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable inputs
[
https://issues.apache.org/jira/browse/CALCITE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131306#comment-16131306
]
MinJi Kim commented on CALCITE-1953:
Here is my initial PR. Thanks!
https://github.com/apache/calcite/pull/521
> Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable
> inputs
> ---
>
> Key: CALCITE-1953
> URL: https://issues.apache.org/jira/browse/CALCITE-1953
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexSimplify, when simplifying NOT(), we negate the input expression. But
> for IS_FALSE/IS_TRUE/IS_NOT_FALSE/IS_NOT_TRUE this cannot be just negated if
> the input is nullable.
> {code}
> IS_FALSE(null) = false
> IS_TRUE(null) = false
> NOT(IS_FALSE(null)) = true != IS_TRUE(null)
> IS_NOT_FALSE(null) = true
> IS_NOT_TRUE(null) = true
> NOT(IS_NOT_FALSE(null)) = false != IS_NOT_TRUE(null)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1953) Reducing NOT() should not collaose NOT(IS_TRUE) to IS_FALSE for nullable inputs
MinJi Kim created CALCITE-1953:
--
Summary: Reducing NOT() should not collaose NOT(IS_TRUE) to
IS_FALSE for nullable inputs
Key: CALCITE-1953
URL: https://issues.apache.org/jira/browse/CALCITE-1953
Project: Calcite
Issue Type: Bug
Reporter: MinJi Kim
Assignee: Julian Hyde
In RexSimplify, when simplifying NOT(), we negate the input expression. But
for IS_FALSE/IS_TRUE/IS_NOT_FALSE/IS_NOT_TRUE this cannot be just negated if
the input is nullable.
{code}
IS_FALSE(null) = false
IS_TRUE(null) = false
NOT(IS_FALSE(null)) = true != IS_TRUE(null)
IS_NOT_FALSE(null) = true
IS_NOT_TRUE(null) = true
NOT(IS_NOT_FALSE(null)) = false != IS_NOT_TRUE(null)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1945) Allow custom return types for AVG/VARIANCE/STDDEV/COVAR
[ https://issues.apache.org/jira/browse/CALCITE-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128197#comment-16128197 ] MinJi Kim commented on CALCITE-1945: I have a first draft of this patch here. I would like to make sure that this is a proper approach. Since we always expand AVG/VAR/STDDEV functions, so I am adding casts before we dividing the numerator and denominator. Let me know if it should be done in another way. Thanks! https://github.com/apache/calcite/pull/518 > Allow custom return types for AVG/VARIANCE/STDDEV/COVAR > --- > > Key: CALCITE-1945 > URL: https://issues.apache.org/jira/browse/CALCITE-1945 > Project: Calcite > Issue Type: Bug >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, return types of AVG() is the input type. So, if the input is > INT/BIGINT type, AVG() is always truncated. Depending on the database, some > database follow this behavior while others (e.g. Oracle/MySQL/etc.) do not > and return floating point values for AVG(). > Similar for other functions mentioned here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1945) Allow custom return types for AVG/VARIANCE/STDDEV/COVAR
MinJi Kim created CALCITE-1945: -- Summary: Allow custom return types for AVG/VARIANCE/STDDEV/COVAR Key: CALCITE-1945 URL: https://issues.apache.org/jira/browse/CALCITE-1945 Project: Calcite Issue Type: Bug Reporter: MinJi Kim Assignee: Julian Hyde For example, return types of AVG() is the input type. So, if the input is INT/BIGINT type, AVG() is always truncated. Depending on the database, some database follow this behavior while others (e.g. Oracle/MySQL/etc.) do not and return floating point values for AVG(). Similar for other functions mentioned here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1936) Allow ROUND() and TRUNCATE() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122810#comment-16122810 ] MinJi Kim commented on CALCITE-1936: I updated the PR. Thanks! https://github.com/apache/calcite/pull/513 > Allow ROUND() and TRUNCATE() to take only one operand > - > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1936) Allow ROUND() and TRUNCATE() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122767#comment-16122767 ] MinJi Kim commented on CALCITE-1936: Yes, I meant TRUNCATE. I updated the title. I will also update the patch soon! Thanks! > Allow ROUND() and TRUNCATE() to take only one operand > - > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CALCITE-1936) Allow ROUND() and TRUNCATE() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim updated CALCITE-1936: --- Summary: Allow ROUND() and TRUNCATE() to take only one operand (was: Allow ROUND() and TRUNC() to take only one operand) > Allow ROUND() and TRUNCATE() to take only one operand > - > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1936) Allow ROUND() and TRUNC() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122424#comment-16122424 ] MinJi Kim commented on CALCITE-1936: Here is a small patch for this jira. Please let me know what you think. Thanks! https://github.com/apache/calcite/pull/513 > Allow ROUND() and TRUNC() to take only one operand > -- > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1936) Allow ROUND() and TRUNC() to take only one operand
MinJi Kim created CALCITE-1936: -- Summary: Allow ROUND() and TRUNC() to take only one operand Key: CALCITE-1936 URL: https://issues.apache.org/jira/browse/CALCITE-1936 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to take only one operand for ease of use. For example, we could allow ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122332#comment-16122332
]
MinJi Kim edited comment on CALCITE-1930 at 8/10/17 9:14 PM:
-
Here is the updated PR: https://github.com/apache/calcite/pull/510
I added tests to agg.iq. Also, the changes to the
AggregateExpandDistinctAggregatesRule to support distinct aggregate calls with
more than one input were not that big, so I made them in this patch. I think
it seems to work fine now, so I added tests in both RelOptRulesTest and agg.iq
with COUNT(DISTINCT A, B). Thanks!
was (Author: minjikim):
Here is the updated PR: https://github.com/apache/calcite/pull/510
I added some more tests to agg.iq. Also, the changes to the
AggregateExpandDistinctAggregatesRule to support distinct aggregate calls with
more than one input were not that big, so I made them here. I think it seems
to work fine now, so I added tests in both RelOptRulesTest and agg.iq with
COUNT(DISTINCT A, B). Thanks!
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122332#comment-16122332
]
MinJi Kim commented on CALCITE-1930:
Here is the updated PR: https://github.com/apache/calcite/pull/510
I added some more tests to agg.iq. Also, the changes to the
AggregateExpandDistinctAggregatesRule to support distinct aggregate calls with
more than one input were not that big, so I made them here. I think it seems
to work fine now, so I added tests in both RelOptRulesTest and agg.iq with
COUNT(DISTINCT A, B). Thanks!
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
[ https://issues.apache.org/jira/browse/CALCITE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120073#comment-16120073 ] MinJi Kim commented on CALCITE-1931: I have updated the pull request with some additional changes for you to review. Thanks! https://github.com/apache/calcite/pull/511 > rank/ntile/etc. functions should not always return INTEGER > -- > > Key: CALCITE-1931 > URL: https://issues.apache.org/jira/browse/CALCITE-1931 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, rank() and percent_rank() both return INTEGER. For rank(), it > would be better to return BIGINT; for percent_rank(), we should actually > return double or float since it is a percent value. There are other rank > functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118728#comment-16118728
]
MinJi Kim commented on CALCITE-1930:
The assumption that the "distinct aggregate call" have only one argument was
always there for converting the single distinct call, but never explicitly
stated. So I added it to make it clear. I don't think it is inherently
necessary, although will need some work to fix. To understand this properly,
if someone uses COUNT(distinct x, y, z), it would be counting distinct
combination of x, y, z? So, two rows with the following (x, y, z) values --
(1, 1, 1), (1, 1, 2) -- would be counted separately? I can try to drop that
assumption in the next patch. Let me know if I have not understood the problem
properly here.
I will also add some queries to agg.iq in the next patch.
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
[ https://issues.apache.org/jira/browse/CALCITE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118693#comment-16118693 ] MinJi Kim commented on CALCITE-1931: I think CUME_DIST() and PERCENT_RANK() for example, should return floating point, since generally their return values are less than or equal to 1 (I looked at Oracle and MS SqlServer, and they both return fractional values and 1 for these functions). I changed the other functions (e.g. NTILE/RANK/DENSE_RANK) to return BIGINT rather than INT. For example, MS SqlServer returns BIGINT for NTILE/RANK/DENSE_RANK functions. I didn't think they were controversial since I don't think CUME_DIST() should return integers, otherwise all the values would be zero. But perhaps somebody is using that behavior somewhere. I can definitely add a way for users to specify return values of RANK functions as in CALCITE-845. I would probably just allow two policies, one for CUME_DIST/PERCENT_RANK and another for NTILE/RANK/DENSE_RANK (with the default being the new behavior as in this patch). Do you think that makes sense? > rank/ntile/etc. functions should not always return INTEGER > -- > > Key: CALCITE-1931 > URL: https://issues.apache.org/jira/browse/CALCITE-1931 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, rank() and percent_rank() both return INTEGER. For rank(), it > would be better to return BIGINT; for percent_rank(), we should actually > return double or float since it is a percent value. There are other rank > functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1932) Project.getPermutation() should return null if a column is repeated
[ https://issues.apache.org/jira/browse/CALCITE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117384#comment-16117384 ] MinJi Kim commented on CALCITE-1932: Thank you for reviewing this PR! Thanks! -Minji https://github.com/apache/calcite/pull/512 > Project.getPermutation() should return null if a column is repeated > --- > > Key: CALCITE-1932 > URL: https://issues.apache.org/jira/browse/CALCITE-1932 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Project.getPermutation() returns true when the project is referencing [$1, > $1]. If a column repeats, it should not be considered a permutation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1932) Project.getPermutation() should return null if a column is repeated
MinJi Kim created CALCITE-1932: -- Summary: Project.getPermutation() should return null if a column is repeated Key: CALCITE-1932 URL: https://issues.apache.org/jira/browse/CALCITE-1932 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde Project.getPermutation() returns true when the project is referencing [$1, $1]. If a column repeats, it should not be considered a permutation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
[ https://issues.apache.org/jira/browse/CALCITE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117196#comment-16117196 ] MinJi Kim commented on CALCITE-1931: Thanks again for reviewing this! https://github.com/apache/calcite/pull/511 > rank/ntile/etc. functions should not always return INTEGER > -- > > Key: CALCITE-1931 > URL: https://issues.apache.org/jira/browse/CALCITE-1931 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, rank() and percent_rank() both return INTEGER. For rank(), it > would be better to return BIGINT; for percent_rank(), we should actually > return double or float since it is a percent value. There are other rank > functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
MinJi Kim created CALCITE-1931: -- Summary: rank/ntile/etc. functions should not always return INTEGER Key: CALCITE-1931 URL: https://issues.apache.org/jira/browse/CALCITE-1931 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde For example, rank() and percent_rank() both return INTEGER. For rank(), it would be better to return BIGINT; for percent_rank(), we should actually return double or float since it is a percent value. There are other rank functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117052#comment-16117052
]
MinJi Kim commented on CALCITE-1930:
Here is an initial fix for this issue that I noticed for converting a single
distinct aggregate call. Please let me know if you have any comments or
feedback. Thanks!
https://github.com/apache/calcite/pull/510
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1930:
---
Description:
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
should be SUM($2).
was:
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
MinJi Kim created CALCITE-1930:
--
Summary: AggregateExpandDistinctAggregatesRule does not expand
aggregates properly
Key: CALCITE-1930
URL: https://issues.apache.org/jira/browse/CALCITE-1930
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037931#comment-16037931
]
MinJi Kim commented on CALCITE-1829:
I updated the PR. Please take a look, thanks again!
https://github.com/apache/calcite/pull/467
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037926#comment-16037926
]
MinJi Kim commented on CALCITE-1829:
No, not really. I was worried that there might be cases that
VisitorDataContext.getValue() or RexLiteral.getValueAs() weren't handling. It
might be better to fail and make sure that the RexLiteral is valid and/or we
are properly handling all data type in VisitorDataContext, rather than silently
return null. I will fix that. Thanks!
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037872#comment-16037872
]
MinJi Kim commented on CALCITE-1829:
[~julianhyde] I updated the PR with the changes. If you can take a look and
let me know of any comments/feedback, it would be great! Thanks!
https://github.com/apache/calcite/pull/467
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037536#comment-16037536
]
MinJi Kim edited comment on CALCITE-1829 at 6/5/17 8:44 PM:
Thanks for the review, [~julianhyde]. I will fix the VisitorDataContext as you
suggested and update the pull request later today. I didn't know about the
RexLiteral.getValueAs(), that's really nice!
The test for SqlToRelConverterTest was added while I was just testing the
changes in VisitorDataContext, and I wanted to see if subquery conversion will
go through this code for timestamps. As you said it doesn't go through the
VisitorDataContext since we generate ISNULL operator which has special
handling. I will remove it.
was (Author: minjikim):
Thanks for the review, [~julianhyde]. I will fix the VisitorDataContext as you
suggested and update the pull request later today.
The test for SqlToRelConverterTest was added while I was just testing the
changes in VisitorDataContext, and I wanted to see if subquery conversion will
go through this code for timestamps. As you said it doesn't go through the
VisitorDataContext since we generate ISNULL operator which has special
handling. I will remove it.
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037536#comment-16037536
]
MinJi Kim commented on CALCITE-1829:
Thanks for the review, [~julianhyde]. I will fix the VisitorDataContext as you
suggested and update the pull request later today.
The test for SqlToRelConverterTest was added while I was just testing the
changes in VisitorDataContext, and I wanted to see if subquery conversion will
go through this code for timestamps. As you said it doesn't go through the
VisitorDataContext since we generate ISNULL operator which has special
handling. I will remove it.
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035880#comment-16035880
]
MinJi Kim commented on CALCITE-1829:
[~julianhyde] Let me know if this looks okay. Thanks!
https://github.com/apache/calcite/pull/467
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1829:
---
Description:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. For example:
{code}
select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
TIMESTAMP '2015-01-01 10:11:12']
{code}
should imply
{code}
select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
{code}
since both timestamps in the first query's filter condition is stronger than
the second query's filter condition.
In RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate
RexImplicationCheckerTest.testSimpleTime
RexImplicationCheckerTest.testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
was:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. For example:
{code}
select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
TIMESTAMP '2015-01-01 10:11:12']
{code}
should imply
{code}
select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
{code}
since both timestamps in the first query satisfies the second query's filter
condition.
In RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate
RexImplicationCheckerTest.testSimpleTime
RexImplicationCheckerTest.testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query's filter condition is stronger than
> the second query's filter condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1829:
---
Description:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. For example:
{code}
select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
TIMESTAMP '2015-01-01 10:11:12']
{code}
should imply
{code}
select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
{code}
since both timestamps in the first query satisfies the second query's filter
condition.
In RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate
RexImplicationCheckerTest.testSimpleTime
RexImplicationCheckerTest.testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
was:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate
RexImplicationCheckerTest.testSimpleTime
RexImplicationCheckerTest.testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. For example:
> {code}
> select hiredate from emp where hiredate IN [TIMESTAMP '2017-01-01 10:11:12',
> TIMESTAMP '2015-01-01 10:11:12']
> {code}
> should imply
> {code}
> select hiredate from emp where hiredate <= TIMESTAMP '2017-12-01 01:02:03'
> {code}
> since both timestamps in the first query satisfies the second query's filter
> condition.
> In RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035698#comment-16035698
]
MinJi Kim commented on CALCITE-1829:
Okay, let me go find an example and update the description to be more
meaningful. Thanks for the quick response, [~julianhyde]!
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. In
> RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1829:
---
Description:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate, testSimpleTime, testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
was:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. In
> RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate, testSimpleTime, testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
[
https://issues.apache.org/jira/browse/CALCITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1829:
---
Description:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate
RexImplicationCheckerTest.testSimpleTime
RexImplicationCheckerTest.testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
was:
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
{code}
RexImplicationCheckerTest.testSimpleDate, testSimpleTime, testSimpleTimestamp
{code}
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
> Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
> --
>
> Key: CALCITE-1829
> URL: https://issues.apache.org/jira/browse/CALCITE-1829
> Project: Calcite
> Issue Type: Bug
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In RexImplicationChecker, we support a lot of operators and types, but it
> looks like time/timestamp/date datatypes are not supported. In
> RexImplicationCheckerTest, there are tests for each of the aforementioned
> datatypes, but are disabled.
> {code}
> RexImplicationCheckerTest.testSimpleDate
> RexImplicationCheckerTest.testSimpleTime
> RexImplicationCheckerTest.testSimpleTimestamp
> {code}
> Running these ignored tests, I get the following error messages.
> {code}
> 2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
> >=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
> 2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
> <=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
> 2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
> <=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
> java.lang.Long
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1829) Add TIME/TIMESTAMP/DATE datatype handling to RexImplicationChecker
MinJi Kim created CALCITE-1829:
--
Summary: Add TIME/TIMESTAMP/DATE datatype handling to
RexImplicationChecker
Key: CALCITE-1829
URL: https://issues.apache.org/jira/browse/CALCITE-1829
Project: Calcite
Issue Type: Bug
Reporter: MinJi Kim
Assignee: Julian Hyde
In RexImplicationChecker, we support a lot of operators and types, but it looks
like time/timestamp/date datatypes are not supported. In
RexImplicationCheckerTest, there are tests for each of the aforementioned
datatypes, but are disabled.
Running these ignored tests, I get the following error messages.
{code}
2017-06-02 17:13:10,028 [main] WARN - Exception thrown while checking if =>
>=($8, 2017-06-03): java.sql.Date cannot be cast to java.lang.Integer
2017-06-02 17:13:10,075 [main] WARN - Exception thrown while checking if =>
<=($9, 00:13:10): java.util.GregorianCalendar cannot be cast to java.lang.Long
2017-06-02 17:13:10,100 [main] WARN - Exception thrown while checking if =>
<=($9, 2017-06-03 00:13:10): java.util.GregorianCalendar cannot be cast to
java.lang.Long
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021492#comment-16021492
]
MinJi Kim edited comment on CALCITE-1800 at 5/23/17 5:11 PM:
-
+1 Looks good to me. Thanks, [~victor.ba...@gmail.com]
[~julianhyde] Do you think it is ready?
was (Author: minjikim):
+1 Looks good to me. Thanks, [~victor.ba...@gmail.com]
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525)
> ... 31 more
> Caused by: java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel
[jira] [Commented] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021492#comment-16021492
]
MinJi Kim commented on CALCITE-1800:
+1 Looks good to me. Thanks, [~victor.ba...@gmail.com]
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525)
> ... 31 more
> Caused by: java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache
[jira] [Comment Edited] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020677#comment-16020677
]
MinJi Kim edited comment on CALCITE-1800 at 5/23/17 5:34 AM:
-
It looks like my previous suggestion is not going to work. In
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(), we have the
following query plan:
{code}
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($0, 100)])
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($2, 1)])
LogicalAggregate(group=[{0}], EXPR$1=[MIN($1)], agg#1=[COUNT()])
LogicalProject(product_id=[$1], store_id=[$19])
LogicalJoin(condition=[=($1, $15)], joinType=[inner])
LogicalTableScan(table=[[foodmart, product]])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
The subtree below "LogicalFilter(condition=[>($0, 100)])" generates the
following sql query, which I believe is correct. Now, with the additional
filter, "LogicalFilter(condition=[>($0, 100)])", we need to make sure that a
new AliasContext is generated.
{code}
SELECT `product`.`product_id`, MIN(`sales_fact_1997`.`store_id`)
FROM `foodmart`.`product`
INNER JOIN `foodmart`.`sales_fact_1997` ON `product`.`product_id` =
`sales_fact_1997`.`product_id`
GROUP BY `product`.`product_id`
HAVING COUNT(*) > 1
{code}
In this case, selectList is null since this is a filter, and we fall through
and never generate a new AliasContext if we use my previously proposed fix.
So, actually we do need the if-else-clause as before. I do think that we need
to be a bit more specific as to when we enter the if-else-clause. We not only
need check that we used the new alias (i.e. needNew is true and neededAlias !=
null), but also check that our aliases is of size 1. Since we could have
aliases = [, ], with neededAlias = t1 (although I
believe this should not happen in our code currently, but I think if our
aliases context has two elements, "t1" and "t2", and we want to re-name the
entire subquery as "t1", that should be a new AliasContext with a single
element).
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
// basically, we did a subSelect() since needNew is set and neededAlias
is not null
// now, we need to make sure that we need to update the alias context.
// if our aliases map has a single element: ,
// then we don't need to rewrite the alias but otherwise, it should be
updated.
if (needNew
&& neededAlias != null
&& (aliases.size() != 1 || !aliases.containsKey(neededAlias))) {
newContext = aliasContext(ImmutableMap.of(neededAlias,
rel.getRowType()), qualified);
} else {
newContext = aliasContext(aliases, qualified);
}
}
return new Builder(rel, clauseList, select, newContext, aliases);
{code}
[~julianhyde] and [~victor.ba...@gmail.com] does this sound reasonable? With
above change, all tests seem to pass too.
was (Author: minjikim):
It looks like my previous suggestion is not going to work. In
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(), we have the
following query plan:
{code}
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($0, 100)])
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($2, 1)])
LogicalAggregate(group=[{0}], EXPR$1=[MIN($1)], agg#1=[COUNT()])
LogicalProject(product_id=[$1], store_id=[$19])
LogicalJoin(condition=[=($1, $15)], joinType=[inner])
LogicalTableScan(table=[[foodmart, product]])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
The subtree below "LogicalFilter(condition=[>($0, 100)])" generates the
following sql query, which I believe is correct. Now, with the additional
filter, "LogicalFilter(condition=[>($0, 100)])", we need to make sure that a
new AliasContext is generated.
{code}
SELECT `product`.`product_id`, MIN(`sales_fact_1997`.`store_id`)
FROM `foodmart`.`product`
INNER JOIN `foodmart`.`sales_fact_1997` ON `product`.`product_id` =
`sales_fact_1997`.`product_id`
GROUP BY `product`.`product_id`
HAVING COUNT(*) > 1
{code}
In this case, selectList is null since this is a filter, and we fall through
and never generate a new AliasContext if we use my previously proposed fix.
So, actually we do need the if-else-clause as before. I do think that we need
to be a bit more specific as to when we enter the if-else-clause. We not only
need check that we used the new alias (i.e. needNew is true and neededAlias !=
null), but also check that our aliases is of size 1. Since we could have
aliases = [, ], with neededAlias = t1 (although I
believe this should not happen in our code currently,
[jira] [Commented] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020677#comment-16020677
]
MinJi Kim commented on CALCITE-1800:
It looks like my previous suggestion is not going to work. In
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(), we have the
following query plan:
{code}
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($0, 100)])
LogicalProject(product_id=[$0], EXPR$1=[$1])
LogicalFilter(condition=[>($2, 1)])
LogicalAggregate(group=[{0}], EXPR$1=[MIN($1)], agg#1=[COUNT()])
LogicalProject(product_id=[$1], store_id=[$19])
LogicalJoin(condition=[=($1, $15)], joinType=[inner])
LogicalTableScan(table=[[foodmart, product]])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
The subtree below "LogicalFilter(condition=[>($0, 100)])" generates the
following sql query, which I believe is correct. Now, with the additional
filter, "LogicalFilter(condition=[>($0, 100)])", we need to make sure that a
new AliasContext is generated.
{code}
SELECT `product`.`product_id`, MIN(`sales_fact_1997`.`store_id`)
FROM `foodmart`.`product`
INNER JOIN `foodmart`.`sales_fact_1997` ON `product`.`product_id` =
`sales_fact_1997`.`product_id`
GROUP BY `product`.`product_id`
HAVING COUNT(*) > 1
{code}
In this case, selectList is null since this is a filter, and we fall through
and never generate a new AliasContext if we use my previously proposed fix.
So, actually we do need the if-else-clause as before. I do think that we need
to be a bit more specific as to when we enter the if-else-clause. We not only
need check that we used the new alias (i.e. needNew is true and neededAlias !=
null), but also check that our aliases is of size 1. Since we could have
aliases = [, ], with neededAlias = t1 (although I
believe this should not happen in our code currently, but I think if our
aliases context has two elements, "t1" and "t2", and we want to re-name the
entire subquery as "t1", that should be a new AliasContext with a single
element).
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
// basically, we did a subSelect() since needNew is set and neededAlias
is not null
// now, we need to make sure that we need to update the alias context.
// if our aliases map has a single element: ,
// then we don't need to rewrite the alias but otherwise, it should be
updated.
if (needNew // if we have renamed
&& neededAlias != null // can't rename to empty
&& aliases.size() != 1 // Even if "t1" is in aliases, if size is >
1 then we should rename.
&& !aliases.containsKey(neededAlias)) {
newContext = aliasContext(ImmutableMap.of(neededAlias,
rel.getRowType()), qualified);
} else {
newContext = aliasContext(aliases, qualified);
}
}
return new Builder(rel, clauseList, select, newContext, aliases); //
<--- I don't recall why I added the needNew check here, and I don't think it is
necessary.
}
{code}
[~julianhyde] and [~victor.ba...@gmail.com] does this sound reasonable? With
above change, all tests seem to pass too.
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> a
[jira] [Comment Edited] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020643#comment-16020643
]
MinJi Kim edited comment on CALCITE-1800 at 5/23/17 4:24 AM:
-
It looks like the problem is whether we should create a new AliasContext. The
plan we get after conversion is as follows. After LogicalUnion, we have an
alias "t1" for the subtree including LogicalUnion and below, with row type
(product_id, net_weight).
{code}
LogicalAggregate(group=[{}], NET_WEIGHT=[SUM($0)])
LogicalProject($f0=[CASE(=($0, 0), $1, 0)])
LogicalUnion(all=[true])
LogicalProject(product_id=[$1], net_weight=[$7])
LogicalTableScan(table=[[foodmart, product]])
LogicalProject(product_id=[$0], net_weight=[0])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
Sine Unions are SET_OP operations, in the Result.builder(), we set the flag
needNew to true (selectList is null in this case) when visiting LogicalProject
above the Union, and so we enter the following if-clause. Now, in this case,
the LogicalProject is reducing the row type to a single column, so we now
generate an incorrect row type for alias "t1". Basically, when the alias is
unchanging, we shouldn't be creating a new alias.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
if (needNew) { // <--- this is where the patch fixes so that we don't
enter here.
newContext =
aliasContext(ImmutableMap.of(neededAlias, rel.getRowType()),
qualified);
} else {
newContext = aliasContext(aliases, qualified);
}
}
{code}
At the minimum, I would change the patch so that it checks that aliases.size()
== 1 and that the aliases are the same (i.e. neededAlias is equal to the only
key is aliases) -- if there are two aliases say "t1" and "t2" in aliases, and
we are collapsing the two aliases into a single alias "t1", even if "t1" is
contained in aliases, we should actually create a new alias. But, I wonder if
we should get rid of it all and revert the code back to what it used to be.
Because I think in this case, we have no selectList, there shouldn't be any
rowtype change.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
newContext = aliasContext(aliases, qualified);
}
{code}
In this case, only one test fails
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(). I am looking into
that right now.
was (Author: minjikim):
It looks like the problem is whether we should create a new AliasContext. The
plan we get after conversion is as follows. After LogicalUnion, we have an
alias "t1" for the subtree including LogicalUnion and below, with row type
(product_id, net_weight).
{code}
LogicalAggregate(group=[{}], NET_WEIGHT=[SUM($0)])
LogicalProject($f0=[CASE(=($0, 0), $1, 0)])
LogicalUnion(all=[true])
LogicalProject(product_id=[$1], net_weight=[$7])
LogicalTableScan(table=[[foodmart, product]])
LogicalProject(product_id=[$0], net_weight=[0])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
Sine Unions are SET_OP operations, in the Result.builder(), we set the flag
needNew to true (selectList is null in this case) when visitng LogicalProject
above the Union, and so we enter the following if-clause. Now, in this case,
the LogicalProject is reducing the row type to a single column, so we now
generate an incorrect row type for aliase "t1". I think basically, when the
alias is unchanging, we shouldn't be creating a new alias.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
if (needNew) { // <--- this is where the patch fixes so that we don't
enter here.
newContext =
aliasContext(ImmutableMap.of(neededAlias, rel.getRowType()),
qualified);
} else {
newContext = aliasContext(aliases, qualified);
}
}
{code}
At the minimum, I would change the patch so that it checks that aliases.size()
== 1 and that the aliases are the same (i.e. neededAlias is equal to the only
key is aliases). But, I wonder if we should get rid of it all and revert the
code back to what it used to be. Because I think in this case, we have no
selectList, there shouldn't be any rowtype change.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
newContext = aliasContext(aliases, qualified);
}
{code}
In this case, only one test fails
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(). I am looking into
that right now.
> JDBC adapter fails to SELECT FROM a UNION query
> ---
[jira] [Commented] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020643#comment-16020643
]
MinJi Kim commented on CALCITE-1800:
It looks like the problem is whether we should create a new AliasContext. The
plan we get after conversion is as follows. After LogicalUnion, we have an
alias "t1" for the subtree including LogicalUnion and below, with row type
(product_id, net_weight).
{code}
LogicalAggregate(group=[{}], NET_WEIGHT=[SUM($0)])
LogicalProject($f0=[CASE(=($0, 0), $1, 0)])
LogicalUnion(all=[true])
LogicalProject(product_id=[$1], net_weight=[$7])
LogicalTableScan(table=[[foodmart, product]])
LogicalProject(product_id=[$0], net_weight=[0])
LogicalTableScan(table=[[foodmart, sales_fact_1997]])
{code}
Sine Unions are SET_OP operations, in the Result.builder(), we set the flag
needNew to true (selectList is null in this case) when visitng LogicalProject
above the Union, and so we enter the following if-clause. Now, in this case,
the LogicalProject is reducing the row type to a single column, so we now
generate an incorrect row type for aliase "t1". I think basically, when the
alias is unchanging, we shouldn't be creating a new alias.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
if (needNew) { // <--- this is where the patch fixes so that we don't
enter here.
newContext =
aliasContext(ImmutableMap.of(neededAlias, rel.getRowType()),
qualified);
} else {
newContext = aliasContext(aliases, qualified);
}
}
{code}
At the minimum, I would change the patch so that it checks that aliases.size()
== 1 and that the aliases are the same (i.e. neededAlias is equal to the only
key is aliases). But, I wonder if we should get rid of it all and revert the
code back to what it used to be. Because I think in this case, we have no
selectList, there shouldn't be any rowtype change.
{code}
} else {
boolean qualified =
!dialect.hasImplicitTableAlias() || aliases.size() > 1;
newContext = aliasContext(aliases, qualified);
}
{code}
In this case, only one test fails
RelToSqlConverterTest.testSelectQueryWithGroupByHaving3(). I am looking into
that right now.
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(Bl
[jira] [Commented] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020504#comment-16020504
]
MinJi Kim commented on CALCITE-1800:
Sure thing! I will take a look it soon.
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525)
> ... 31 more
> Caused by: java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.re
[jira] [Comment Edited] (CALCITE-1800) JDBC adapter fails to SELECT FROM a UNION query
[
https://issues.apache.org/jira/browse/CALCITE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020504#comment-16020504
]
MinJi Kim edited comment on CALCITE-1800 at 5/23/17 1:06 AM:
-
Sure thing! I will take a look at it soon.
was (Author: minjikim):
Sure thing! I will take a look it soon.
> JDBC adapter fails to SELECT FROM a UNION query
>
>
> Key: CALCITE-1800
> URL: https://issues.apache.org/jira/browse/CALCITE-1800
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.9.0
>Reporter: Viktor Batytskyi
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Relational representation of the following query fails to be converter to sql
> string in Calcite:
> {code}
> select sum(case when "product_id"=0 then "net_weight" else 0 end) as
> net_weight
> from ( select "product_id", "net_weight" from "product"
> union all
> select "product_id", 0 as "net_weight" from "sales_fact_1997" ) t0
> {code}
> The conversion fails with:
> {code}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Aggregate)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:528)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:96)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:100)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:1559)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testUnionWrappedInASelect(RelToSqlConverterTest.java:654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:525)
> ... 31 more
> Caused by: java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981773#comment-15981773
]
MinJi Kim commented on CALCITE-1753:
[~julianhyde] Yes it is! Sorry, if I wasn't clear earlier. Thanks for
reviewing it!
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975646#comment-15975646
]
MinJi Kim commented on CALCITE-1753:
It looks like I spoke too soon. I tried enabling ProjectFilterTransposeRule to
use ExprCondition.TRUE, but that seem to cause a lot of issues. For one,
pushing more general expressions down results in these weird plans where the
filter isn't evaluating anything and pushes it to the project below to evaluate
the filter condition and the filter just checks the condition to be true/false.
I didn't think it was buying much, since pushing down the input reference
reduces the number of columns selected and is useful, but pushing the filter
condition evaluation didn't seem to be as useful in my mind. I think for now,
I would be happy to keep it as it is. Do you agree?
{code}
LogicalFilter(condition=[$3])
LogicalProject(ENAME=[$1], SAL=[$5], DEPTNO=[$7], >=[>($5, 5000)])
{code}
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975607#comment-15975607
]
MinJi Kim commented on CALCITE-1753:
[~julianhyde] and [~jni] I updated the pull request. Please take a look.
https://github.com/apache/calcite/pull/425/
I noticed that ProjectFilterTransposeRule and ProjectSetOpTransposeRule also
use PushProjector. I thought ProjectFilterTransposeRule seemed fine to change
it to use ExprCondition.TRUE, but thought SetOp might need a little bit more
thought. So, I left both of them as is. Let me know. While the patch is in
review, I will continue work on making the other two rules to default to TRUE,
and add more tests if I think that makes sense. Thanks!
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
> Fix For: 1.13.0
>
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971874#comment-15971874
]
MinJi Kim edited comment on CALCITE-1753 at 4/18/17 12:15 AM:
--
[~julianhyde] Sure thing. Will make the changes. I can test and see if we can
change ExprCondition.TRUE as the default. I will add some more tests in that
case as well.
was (Author: minjikim):
[~julianhyde] Sure thing. Will make the changes. I can test and if we can
change ExprCondition.TRUE as the default. I will add some more tests in that
case as well.
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971874#comment-15971874
]
MinJi Kim commented on CALCITE-1753:
[~julianhyde] Sure thing. Will make the changes. I can test and if we can
change ExprCondition.TRUE as the default. I will add some more tests in that
case as well.
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969827#comment-15969827
]
MinJi Kim commented on CALCITE-1753:
I updated the PR with some changes. Please take a look at let me know if this
is in the right direction! Thanks!
https://github.com/apache/calcite/pull/425/
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15968425#comment-15968425
]
MinJi Kim commented on CALCITE-1753:
[~julianhyde] Thanks. Strong looks like what I was looking for! I will work
on updating the patch.
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15968112#comment-15968112
]
MinJi Kim commented on CALCITE-1753:
I agree with what you said, [~jni]. Do you have a suggestion as to how we
would we distinguish that for the operators? I suggested having another
preserveExprCondition to allow the user of the rule to specify which operations
they would want to push past outer joins, but that seems to be shifting the
work to the user vs. figuring it out automatically.
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965420#comment-15965420
]
MinJi Kim commented on CALCITE-1753:
I debated between adding another preserveExprCondition to PushProjector that
would apply to outer join's nullable side. I couldn't think of a case where
that would be useful (at least, use cases that I could think of, I wouldn't
want to push any expressions to the nullable side of an outer join). Let me
know if you think it would be. I will update the pull request.
https://github.com/apache/calcite/pull/425
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
>LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
>LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1753) ProjectJoinTransposeRule with preserveExprCondition pushes projects below outer-joins
MinJi Kim created CALCITE-1753:
--
Summary: ProjectJoinTransposeRule with preserveExprCondition
pushes projects below outer-joins
Key: CALCITE-1753
URL: https://issues.apache.org/jira/browse/CALCITE-1753
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
I am pushing case statements past joins using ProjectJoinTransposeRule. For
inner joins, the current behavior seems fine, but outer joins can lead to weird
behavior, where the project is below the join and nulls can cause issues.
{code}
select
count(*), case when t3.a3 is not null then t3.a3 else 100 end
from
t1 left outer join t3 on t1.c1 = t3.c3
group by
case when t3.a3 is not null then t3.a3 else 100 end
order by
case when t3.a3 is not null then t3.a3 else 100 end
{code}
Currently, ProjectJoinTransposeRule will push the case statement below the join
as below. But, this case statement shouldn't be pushed. The query shouldn't
return null but instead as 100 for any "unmatched" join condition since it is a
left outer join with a case statement. But, the current plan would not prevent
that.
{code}
LogicalProject with case statement
LogicalJoin
LogicalTableScan(table=[t1])
LogicalTableScan(table=[t3])
{code}
{code}
LogicalProject
LogicalJoin
LogicalProject with case statement
LogicalTableScan(table=[t1])
LogicalTableScan(table=[t3])
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1747) RelMdColumnUniqueness for HepRelVertex
[
https://issues.apache.org/jira/browse/CALCITE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963796#comment-15963796
]
MinJi Kim commented on CALCITE-1747:
I ran a clean full build (mvn clean install) on calcite root and everything
passed. I was concerned that I might be missing something. Any specific test
cases that I should look into adding?
> RelMdColumnUniqueness for HepRelVertex
> --
>
> Key: CALCITE-1747
> URL: https://issues.apache.org/jira/browse/CALCITE-1747
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In generated code/JaninoRelMetadataProvider, areColumnsUnique() is supported
> for HepRelVertex, by using HepRelVertex.getCurrentRel(). In the underlying
> RelMetadata (RelMdColumnUniqueness.java), the same code is disabled.
> This is causing some problems for me since I am trying to use
> RelMdColumnUniquess without going through the JaninoRelMetadataProvider For
> me, enabling the same code in RelMdColumnUniquess solved the problem for me.
> Although I am uploading a small patch for this soon, I wanted to see if there
> were any concerns for enabling RelMdColumnUniqueness for HepRelVertex.
> {code}
> private java.lang.Boolean areColumnsUnique_(
> org.apache.calcite.rel.RelNode r,
> org.apache.calcite.rel.metadata.RelMetadataQuery mq,
> org.apache.calcite.util.ImmutableBitSet a0,
> boolean a1) {
> switch (relClasses.indexOf(r.getClass())) {
> default:
> return provider0.areColumnsUnique((org.apache.calcite.rel.RelNode) r,
> mq, a0, a1);
> case 2:
> return
> provider0.areColumnsUnique((org.apache.calcite.plan.volcano.RelSubset) r, mq,
> a0, a1);
> case 3:
> return areColumnsUnique(((org.apache.calcite.plan.hep.HepRelVertex)
> r).getCurrentRel(), mq, a0, a1);
> case 4:
> case 5:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.convert.Converter) r, mq,
> a0, a1);
> case 6:
> case 24:
> case 30:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Aggregate) r, mq, a0,
> a1);
> case 8:
> case 32:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Correlate) r, mq, a0,
> a1);
> case 9:
> case 33:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Exchange) r, mq, a0,
> a1);
> case 10:
> case 25:
> case 34:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Filter)
> r, mq, a0, a1);
> case 11:
> case 35:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Intersect) r, mq, a0,
> a1);
> case 12:
> case 27:
> case 36:
> case 48:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Join) r,
> mq, a0, a1);
> case 13:
> case 37:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Minus)
> r, mq, a0, a1);
> case 14:
> case 26:
> case 38:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Project)
> r, mq, a0, a1);
> case 15:
> case 39:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Sort) r,
> mq, a0, a1);
> case 18:
> case 28:
> case 42:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.TableScan) r, mq, a0,
> a1);
> case 19:
> case 43:
> case 50:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.SetOp)
> r, mq, a0, a1);
> case 20:
> case 44:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Values)
> r, mq, a0, a1);
> case -1:
> throw new
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$NoHandler(r.getClass());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1747) RelMdColumnUniqueness for HepRelVertex
[
https://issues.apache.org/jira/browse/CALCITE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963682#comment-15963682
]
MinJi Kim commented on CALCITE-1747:
I wanted to make sure that this isn't going to cause some regression. I wasn't
sure if this was disabled for a specific reason unknown to me. Thanks!
https://github.com/apache/calcite/pull/420
> RelMdColumnUniqueness for HepRelVertex
> --
>
> Key: CALCITE-1747
> URL: https://issues.apache.org/jira/browse/CALCITE-1747
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> In generated code/JaninoRelMetadataProvider, areColumnsUnique() is supported
> for HepRelVertex, by using HepRelVertex.getCurrentRel(). In the underlying
> RelMetadata (RelMdColumnUniqueness.java), the same code is disabled.
> This is causing some problems for me since I am trying to use
> RelMdColumnUniquess without going through the JaninoRelMetadataProvider For
> me, enabling the same code in RelMdColumnUniquess solved the problem for me.
> Although I am uploading a small patch for this soon, I wanted to see if there
> were any concerns for enabling RelMdColumnUniqueness for HepRelVertex.
> {code}
> private java.lang.Boolean areColumnsUnique_(
> org.apache.calcite.rel.RelNode r,
> org.apache.calcite.rel.metadata.RelMetadataQuery mq,
> org.apache.calcite.util.ImmutableBitSet a0,
> boolean a1) {
> switch (relClasses.indexOf(r.getClass())) {
> default:
> return provider0.areColumnsUnique((org.apache.calcite.rel.RelNode) r,
> mq, a0, a1);
> case 2:
> return
> provider0.areColumnsUnique((org.apache.calcite.plan.volcano.RelSubset) r, mq,
> a0, a1);
> case 3:
> return areColumnsUnique(((org.apache.calcite.plan.hep.HepRelVertex)
> r).getCurrentRel(), mq, a0, a1);
> case 4:
> case 5:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.convert.Converter) r, mq,
> a0, a1);
> case 6:
> case 24:
> case 30:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Aggregate) r, mq, a0,
> a1);
> case 8:
> case 32:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Correlate) r, mq, a0,
> a1);
> case 9:
> case 33:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Exchange) r, mq, a0,
> a1);
> case 10:
> case 25:
> case 34:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Filter)
> r, mq, a0, a1);
> case 11:
> case 35:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.Intersect) r, mq, a0,
> a1);
> case 12:
> case 27:
> case 36:
> case 48:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Join) r,
> mq, a0, a1);
> case 13:
> case 37:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Minus)
> r, mq, a0, a1);
> case 14:
> case 26:
> case 38:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Project)
> r, mq, a0, a1);
> case 15:
> case 39:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Sort) r,
> mq, a0, a1);
> case 18:
> case 28:
> case 42:
> return
> provider0.areColumnsUnique((org.apache.calcite.rel.core.TableScan) r, mq, a0,
> a1);
> case 19:
> case 43:
> case 50:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.SetOp)
> r, mq, a0, a1);
> case 20:
> case 44:
> return provider0.areColumnsUnique((org.apache.calcite.rel.core.Values)
> r, mq, a0, a1);
> case -1:
> throw new
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$NoHandler(r.getClass());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1747) RelMdColumnUniqueness for HepRelVertex
MinJi Kim created CALCITE-1747:
--
Summary: RelMdColumnUniqueness for HepRelVertex
Key: CALCITE-1747
URL: https://issues.apache.org/jira/browse/CALCITE-1747
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
In generated code/JaninoRelMetadataProvider, areColumnsUnique() is supported
for HepRelVertex, by using HepRelVertex.getCurrentRel(). In the underlying
RelMetadata (RelMdColumnUniqueness.java), the same code is disabled.
This is causing some problems for me since I am trying to use
RelMdColumnUniquess without going through the JaninoRelMetadataProvider For
me, enabling the same code in RelMdColumnUniquess solved the problem for me.
Although I am uploading a small patch for this soon, I wanted to see if there
were any concerns for enabling RelMdColumnUniqueness for HepRelVertex.
{code}
private java.lang.Boolean areColumnsUnique_(
org.apache.calcite.rel.RelNode r,
org.apache.calcite.rel.metadata.RelMetadataQuery mq,
org.apache.calcite.util.ImmutableBitSet a0,
boolean a1) {
switch (relClasses.indexOf(r.getClass())) {
default:
return provider0.areColumnsUnique((org.apache.calcite.rel.RelNode) r, mq,
a0, a1);
case 2:
return
provider0.areColumnsUnique((org.apache.calcite.plan.volcano.RelSubset) r, mq,
a0, a1);
case 3:
return areColumnsUnique(((org.apache.calcite.plan.hep.HepRelVertex)
r).getCurrentRel(), mq, a0, a1);
case 4:
case 5:
return
provider0.areColumnsUnique((org.apache.calcite.rel.convert.Converter) r, mq,
a0, a1);
case 6:
case 24:
case 30:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Aggregate)
r, mq, a0, a1);
case 8:
case 32:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Correlate)
r, mq, a0, a1);
case 9:
case 33:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Exchange)
r, mq, a0, a1);
case 10:
case 25:
case 34:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Filter) r,
mq, a0, a1);
case 11:
case 35:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Intersect)
r, mq, a0, a1);
case 12:
case 27:
case 36:
case 48:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Join) r,
mq, a0, a1);
case 13:
case 37:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Minus) r,
mq, a0, a1);
case 14:
case 26:
case 38:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Project)
r, mq, a0, a1);
case 15:
case 39:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Sort) r,
mq, a0, a1);
case 18:
case 28:
case 42:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.TableScan)
r, mq, a0, a1);
case 19:
case 43:
case 50:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.SetOp) r,
mq, a0, a1);
case 20:
case 44:
return provider0.areColumnsUnique((org.apache.calcite.rel.core.Values) r,
mq, a0, a1);
case -1:
throw new
org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$NoHandler(r.getClass());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15527354#comment-15527354 ] MinJi Kim commented on CALCITE-1342: Oh, that's weird. I do a full build (mvn clean install, just to be sure), and I thought that would run all tests including Quidem. I will keep an eye out for it next time. > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.9.0 > > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1380) Redshift jdbc driver returns "POSTGRES" for its database product name
MinJi Kim created CALCITE-1380: -- Summary: Redshift jdbc driver returns "POSTGRES" for its database product name Key: CALCITE-1380 URL: https://issues.apache.org/jira/browse/CALCITE-1380 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde It looks like Redshift jdbc driver getMetaData().getDatabaseProductName() returns postgres. As a result, Redshift is considered as Postgres (and we fetch incorrect SqlDialect for Redshift). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1372) Calcite generate wrong field names in JDBC adapter
[
https://issues.apache.org/jira/browse/CALCITE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491849#comment-15491849
]
MinJi Kim commented on CALCITE-1372:
+1. It looks good to me. I am debugging something related, but it turns out
it is not the same problem (I tried out your patch to see if it solved the
problem). Once I pinpoint the problem, I will upload a patch for review under
a separate jira.
> Calcite generate wrong field names in JDBC adapter
> --
>
> Key: CALCITE-1372
> URL: https://issues.apache.org/jira/browse/CALCITE-1372
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
> Environment: This bug was detected using an Oracle database and the
> calcite version 1.8.0.
>Reporter: Miguel Oliveira
>Assignee: Julian Hyde
>Priority: Critical
> Labels: adapters, jdbc
> Fix For: 1.9.0
>
>
> For example, this query:
> {quote}
> SELECT v1272.`QUESTN_LBL` `Label (Question Metrics)`,v1274.`LBL` `Label
> (Question)`,v1272.`CLICKTHRU_CNT` `Click Thru Count (Question
> Metrics)`,v1272.`CLICKTHRU_RATIO` `Click Thru Ratio (Question
> Metrics)`,v1272.`DATE` `Date (Question Metrics)`,v1272.`HAS_RESPONSES` `Has
> Responses (Question Metrics)`,v1272.`LOCALE_KEY` `Locale (Question
> Metrics)`,v1272.`QUESTN_CNT` `Question Count (Question
> Metrics)`,v1272.`QUESTN_KEY` `NAVIGATION_8_QUESTION` FROM
> DW_REPORTING.QUESTION v1272 LEFT JOIN DW_REPORTING.METRICS v1274 ON
> v1272.`QUESTN_KEY` = v1274.`QUESTN_KEY` WHERE UPPER(CAST(v1274.`LBL` AS
> VARCHAR(1000))) LIKE UPPER('% den %')
> {quote}
> Generates the following SQL query:
> {quote} SELECT "QUESTN_LBL" "Label (Question Metrics)", "LBL" "Label
> (Question)", "CLICKTHRU_CNT" "Click Thru Count (Question Met",
> "CLICKTHRU_RATIO" "Click Thru Ratio (Question Met", "DATE" "Date (Question
> Metrics)", "HAS_RESPONSES" "Has Responses (Question Metric", "LOCALE_KEY"
> "Locale (Question Metrics)", "QUESTN_CNT" "Question Count (Question Metri",
> "QUESTN_KEY" "NAVIGATION_8_QUESTION", "ID", "QUESTN_KEY0" "QUESTN_KEY"
> FROM (SELECT "ID", "QUESTN_KEY", "LOCALE_KEY", "QUESTN_LBL", "DATE",
> "QUESTN_CNT", "CLICKTHRU_CNT", "CLICKTHRU_RATIO", "HAS_RESPONSES"
> FROM "DW_REPORTING"."QUESTION") "t"
> LEFT JOIN (SELECT "QUESTN_KEY", "LBL"
> FROM "DW_REPORTING"."METRICS") "t0" ON "t"."QUESTN_KEY" = "t0"."QUESTN_KEY"
> WHERE UPPER("t0"."LBL") LIKE UPPER('% den %')
> {quote}
> The problem here is with the "QUESTN_KEY0" doesn't exist, Both "t" and "t0"
> have the "QUESTN_KEY" field and after the JdbcFilter, the table alias "t" and
> "t0" seems to disappear.
> This is the generated plan:
> {noformat}
> [TABLE, #ID {PLAN=JdbcToEnumerableConverter
>JdbcProject(Label (Question Metrics)=[$3], Label (Question)=[$10], Click
> Thru Count (Question Metrics)=[$6], Click Thru Ratio (Question Metrics)=[$7],
> Date (Question Metrics)=[$4], Has Responses (Question Metrics)=[$8], Locale
> (Question Metrics)=[$2], Question Count (Question Metrics)=[$5],
> NAVIGATION_8_QUESTION=[$1], ID=[$0], QUESTN_KEY=[$9])
> JdbcFilter(condition=[LIKE(UPPER(CAST($10):VARCHAR(1000) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"), UPPER('% den %'))])
>JdbcJoin(condition=[=($1, $9)], joinType=[left])
> JdbcProject(ID=[$0], QUESTN_KEY=[$1], LOCALE_KEY=[$2],
> QUESTN_LBL=[$3], DATE=[$4], QUESTN_CNT=[$5], CLICKTHRU_CNT=[$6],
> CLICKTHRU_RATIO=[$8], HAS_RESPONSES=[$9])
>JdbcTableScan(table=[[DW_REPORTING, QUESTION]])
> JdbcProject(QUESTN_KEY=[$0], LBL=[$1])
>JdbcTableScan(table=[[DW_REPORTING, METRICS]])
> , }]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15471264#comment-15471264 ] MinJi Kim commented on CALCITE-1342: Okay, will remember from now on! Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/cb356d8a > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.9.0 > > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim resolved CALCITE-1342. Resolution: Fixed Fix Version/s: 1.9.0 > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.9.0 > > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468909#comment-15468909 ] MinJi Kim commented on CALCITE-1342: Okay, sure. I will make the changes. I will give it a try at my first commit! :) > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1110) remove or relocate shaded jackson in Avatica
[
https://issues.apache.org/jira/browse/CALCITE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468739#comment-15468739
]
MinJi Kim commented on CALCITE-1110:
I am curious about what is being considered to resolve this issue. I am having
similar issue with jackson/fasterxml that is being used in Drill. I have
shaded the jackson packages in Avatica in my local build to move forward with
what I am working on, so if it would help to upload this patch to start a
discussion, I am more than happy to do so. Thanks!
> remove or relocate shaded jackson in Avatica
>
>
> Key: CALCITE-1110
> URL: https://issues.apache.org/jira/browse/CALCITE-1110
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: 1.6.0, 1.5.0
>Reporter: Kai Gülzau
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.9.0
>
>
> The avatica jar includes a shaded version of jackson under the original
> package path.
> This shaded version interferes with other jackson versions in the classpath.
> Currently this prevents us from using jackson functionality which is only
> implemented in newer versions.
> https://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3C977C7450-18F4-48E2-A970-69B7E3E1BD2C%40apache.org%3E
> {quote}
> Is it reasonable to have a maven profile that uses jackson as “provided”[1]
> rather than shading? This would not be the default — the default would be
> continue to use a shaded version of jackson (relocated to
> org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed
> calcite/avatica in a container might appreciate a lighter weight option.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15454350#comment-15454350 ] MinJi Kim commented on CALCITE-1342: [~julianhyde] I uploaded an updated patch. Please let me know if there is anything that I should address. Thanks! > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15451045#comment-15451045 ] MinJi Kim commented on CALCITE-1342: Will do! I am sorry for the delay. I got caught in something, and have been meaning to get back to this for a while. I will try to get to this this week (or this weekend!). > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404658#comment-15404658 ] MinJi Kim commented on CALCITE-1342: I made a small change to use rel factories in ProjectPusher. Thanks! https://github.com/apache/calcite/pull/265 > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
[ https://issues.apache.org/jira/browse/CALCITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim updated CALCITE-1342: --- Description: I was playing around with some new ideas in drill, and wanted to use ProjectPusher, which has a lot of useful utility functions. ProjectPusher returns new nodes, but they are LogicalProjects/LogicalFilters. It would be more useful if the user of ProjectPusher could specify the rel factories to use. (was: I was playing around with some new ideas in drill, and wanted to use ProjectPusher, which has done a lot of useful utility functions. ProjectPusher returns new nodes, but they are LogicalProjects/LogicalFilters. It would be more useful if the user of ProjectPusher could specify the rel factories to use.) > ProjectPusher should use rel factories when creating new rels, e.g. > project/filter > -- > > Key: CALCITE-1342 > URL: https://issues.apache.org/jira/browse/CALCITE-1342 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > I was playing around with some new ideas in drill, and wanted to use > ProjectPusher, which has a lot of useful utility functions. ProjectPusher > returns new nodes, but they are LogicalProjects/LogicalFilters. It would be > more useful if the user of ProjectPusher could specify the rel factories to > use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1342) ProjectPusher should use rel factories when creating new rels, e.g. project/filter
MinJi Kim created CALCITE-1342: -- Summary: ProjectPusher should use rel factories when creating new rels, e.g. project/filter Key: CALCITE-1342 URL: https://issues.apache.org/jira/browse/CALCITE-1342 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde I was playing around with some new ideas in drill, and wanted to use ProjectPusher, which has done a lot of useful utility functions. ProjectPusher returns new nodes, but they are LogicalProjects/LogicalFilters. It would be more useful if the user of ProjectPusher could specify the rel factories to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
[ https://issues.apache.org/jira/browse/CALCITE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398417#comment-15398417 ] MinJi Kim commented on CALCITE-1333: [~julianhyde] I looked through CALCITE-1043. It looks like patch for CALCITE-1200 (by [~venki387]) already made most of the changes in the patch for CALCITE-1043. I pulled in the missing pieces and updated the pull request, https://github.com/apache/calcite/pull/262. > AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of > operator instance > -- > > Key: CALCITE-1333 > URL: https://issues.apache.org/jira/browse/CALCITE-1333 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > In JdbcAggregate, there is a list of functions that can be implemented and > therefore pushed into the underlying database. The list of functions uses > operator instance, but it would be better to use SqlKind. This is > particularly relevant in case a user creates his own operators (e.g. Drill > wraps some of calcite's operators), so comparing instances will not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
[ https://issues.apache.org/jira/browse/CALCITE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398292#comment-15398292 ] MinJi Kim commented on CALCITE-1333: I will take a look at CALCITE-1043. From my initial glance, I think CALCITE-1043 might be broader than this JIRA. If that is the case, I will update the patch to address CALCITE-1043. > AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of > operator instance > -- > > Key: CALCITE-1333 > URL: https://issues.apache.org/jira/browse/CALCITE-1333 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > In JdbcAggregate, there is a list of functions that can be implemented and > therefore pushed into the underlying database. The list of functions uses > operator instance, but it would be better to use SqlKind. This is > particularly relevant in case a user creates his own operators (e.g. Drill > wraps some of calcite's operators), so comparing instances will not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
[ https://issues.apache.org/jira/browse/CALCITE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398280#comment-15398280 ] MinJi Kim commented on CALCITE-1333: Here is my initial patch. Please let me know if there are any concerns. Thanks! https://github.com/apache/calcite/pull/262 > AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of > operator instance > -- > > Key: CALCITE-1333 > URL: https://issues.apache.org/jira/browse/CALCITE-1333 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > In JdbcAggregate, there is a list of functions that can be implemented and > therefore pushed into the underlying database. The list of functions uses > operator instance, but it would be better to use SqlKind. This is > particularly relevant in case a user creates his own operators (e.g. Drill > wraps some of calcite's operators), so comparing instances will not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
[ https://issues.apache.org/jira/browse/CALCITE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim updated CALCITE-1333: --- Description: In JdbcAggregate, there is a list of functions that can be implemented and therefore pushed into the underlying database. The list of functions uses operator instance, but it would be better to use SqlKind. This is particularly relevant in case a user creates his own operators (e.g. Drill wraps some of calcite's operators), so comparing instances will not work. (was: In JdbcAggregate, there is a list of functions that can be implemented and therefore pushed into the underlying database. The list of functions uses operator instance, but it would be better to use SqlKind. This is particularly relevant in case a user creates his own operators (e.g. Drill wraps some of calcite's operators), so comparing instances does not work.) > AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of > operator instance > -- > > Key: CALCITE-1333 > URL: https://issues.apache.org/jira/browse/CALCITE-1333 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > In JdbcAggregate, there is a list of functions that can be implemented and > therefore pushed into the underlying database. The list of functions uses > operator instance, but it would be better to use SqlKind. This is > particularly relevant in case a user creates his own operators (e.g. Drill > wraps some of calcite's operators), so comparing instances will not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
[ https://issues.apache.org/jira/browse/CALCITE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MinJi Kim updated CALCITE-1333: --- Description: In JdbcAggregate, there is a list of functions that can be implemented and therefore pushed into the underlying database. The list of functions uses operator instance, but it would be better to use SqlKind. This is particularly relevant in case a user creates his own operators (e.g. Drill wraps some of calcite's operators), so comparing instances does not work. (was: In JdbcAggregate, there is a list of functions that can be implemented and therefore pushed into the underlying database. The list of functions use operator instance to check, but it would be better to use SqlKind. This is particularly relevant in case a user creates his own operators (e.g. Drill wraps some of calcite's operators), so comparing instances does not work.) > AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of > operator instance > -- > > Key: CALCITE-1333 > URL: https://issues.apache.org/jira/browse/CALCITE-1333 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > In JdbcAggregate, there is a list of functions that can be implemented and > therefore pushed into the underlying database. The list of functions uses > operator instance, but it would be better to use SqlKind. This is > particularly relevant in case a user creates his own operators (e.g. Drill > wraps some of calcite's operators), so comparing instances does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1333) AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance
MinJi Kim created CALCITE-1333: -- Summary: AggFunctions supported by JdbcAggregate should depend on SqlKind, instead of operator instance Key: CALCITE-1333 URL: https://issues.apache.org/jira/browse/CALCITE-1333 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde In JdbcAggregate, there is a list of functions that can be implemented and therefore pushed into the underlying database. The list of functions use operator instance to check, but it would be better to use SqlKind. This is particularly relevant in case a user creates his own operators (e.g. Drill wraps some of calcite's operators), so comparing instances does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397894#comment-15397894
]
MinJi Kim commented on CALCITE-1332:
[~julianhyde] I have made updates to the patch for you to review. Thanks!
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
> mytable2.id
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select name from mydb.mytable inner join mydb.mytable2 on
> mydb.mytable.id = mydb.mytable2.id
> NAME
> --
> Steven
> {code}
> {code}
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYTABLE"."ID" = "MYTABLE2"."ID"
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
> SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
> ID NAME FN
>
> LN
>ID
> --- --
>
>
>
> ---
> 100 Steven steven
>
> even
>100
> 1 record(s) selected.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396925#comment-15396925
]
MinJi Kim commented on CALCITE-1332:
[~julianhyde] I am still working on a few cases with filters and joins. I will
update patch when it is ready.
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
> mytable2.id
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select name from mydb.mytable inner join mydb.mytable2 on
> mydb.mytable.id = mydb.mytable2.id
> NAME
> --
> Steven
> {code}
> {code}
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYTABLE"."ID" = "MYTABLE2"."ID"
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
> SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
> ID NAME FN
>
> LN
>ID
> --- --
>
>
>
> ---
> 100 Steven steven
>
> even
>100
> 1 record(s) selected.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396240#comment-15396240
]
MinJi Kim commented on CALCITE-1332:
Thanks, [~julianhyde]! I think the alias definitely makes things cleaner. I
will give it a try and upload a new patch for you to review.
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
> mytable2.id
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select name from mydb.mytable inner join mydb.mytable2 on
> mydb.mytable.id = mydb.mytable2.id
> NAME
> --
> Steven
> {code}
> {code}
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYTABLE"."ID" = "MYTABLE2"."ID"
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
> SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
> ID NAME FN
>
> LN
>ID
> --- --
>
>
>
> ---
> 100 Steven steven
>
> even
>100
> 1 record(s) selected.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1332:
---
Description:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
mytable2.id
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
ID NAME FN
LN
ID
--- --
---
100 Steven steven
even
100
1 record(s) selected.
{code}
was:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
mytable2.id
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
WORKS!
{code}
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
> mytable2.id
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
>
[jira] [Updated] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1332:
---
Description:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
mytable2.id
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
ID NAME FN
LN
ID
--- --
---
100 Steven steven
even
100
1 record(s) selected.
{code}
was:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
mytable2.id
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
ID NAME FN
LN
ID
--- --
---
100 Steven steven
even
100
1 record(s) selected.
{code}
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https
[jira] [Updated] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1332:
---
Description:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
mytable2.id
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
WORKS!
{code}
was:
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
WORKS!
{code}
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on mytable.id =
> mytable2.id
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> {code}
> {code}
> db2 => select name from mydb.mytable inner join mydb.mytable2 on
> mydb.mytable.id = mydb.mytable2.id
> NAME
> --
> Steven
> {code}
> {code}
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYTABLE"."ID" = "MYTABLE2"."ID"
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
> SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
> WORKS!
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1332) DB2 requires fully qualified names in join condition
[
https://issues.apache.org/jira/browse/CALCITE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396134#comment-15396134
]
MinJi Kim commented on CALCITE-1332:
[~julianhyde] I am sure if this is the best way to solve this problem. Please
take a look and let me know if you have any suggestions or comments. Thanks!
https://github.com/apache/calcite/pull/261
> DB2 requires fully qualified names in join condition
>
>
> Key: CALCITE-1332
> URL: https://issues.apache.org/jira/browse/CALCITE-1332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I tried joining tables in DB2 and it looks like DB2 dialect requires the
> fully qualified (with db name, table name, and column name) in the join
> condition. Also, if quoted, the identifiers need to be separated, e.g.
> "MYDB.MYTABLE" will not work, but "MYDB"."MYTABLE" will.
> {code}
> db2 => select * from mydb.mytable inner join mydb.mytable2 on
> "mydb.mytable".id = "mydb.mytable2".id
> SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> {code}
> {code}
> db2 => select name from mydb.mytable inner join mydb.mytable2 on
> mydb.mytable.id = mydb.mytable2.id
> NAME
> --
> Steven
> {code}
> {code}
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYTABLE"."ID" = "MYTABLE2"."ID"
> SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
> SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
> SQLSTATE=42703
> db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
> "MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
> WORKS!
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1332) DB2 requires fully qualified names in join condition
MinJi Kim created CALCITE-1332:
--
Summary: DB2 requires fully qualified names in join condition
Key: CALCITE-1332
URL: https://issues.apache.org/jira/browse/CALCITE-1332
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
I tried joining tables in DB2 and it looks like DB2 dialect requires the fully
qualified (with db name, table name, and column name) in the join condition.
Also, if quoted, the identifiers need to be separated, e.g. "MYDB.MYTABLE" will
not work, but "MYDB"."MYTABLE" will.
{code}
db2 => select * from mydb.mytable inner join mydb.mytable2 on "mydb.mytable".id
= "mydb.mytable2".id
SQL0206N "mydb.mytable.ID" is not valid in the context where it is used.
SQLSTATE=42703
{code}
{code}
db2 => select name from mydb.mytable inner join mydb.mytable2 on
mydb.mytable.id = mydb.mytable2.id
NAME
--
Steven
{code}
{code}
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYTABLE"."ID" = "MYTABLE2"."ID"
SQL0206N "MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB.MYTABLE"."ID" = "MYDB.MYTABLE2"."ID"
SQL0206N "MYDB.MYTABLE.ID" is not valid in the context where it is used.
SQLSTATE=42703
db2 => select * from "MYDB"."MYTABLE" inner join "MYDB"."MYTABLE2" on
"MYDB"."MYTABLE"."ID" = "MYDB"."MYTABLE2"."ID"
WORKS!
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1330) DB2 does not support character sets in data type
[
https://issues.apache.org/jira/browse/CALCITE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392885#comment-15392885
]
MinJi Kim commented on CALCITE-1330:
https://github.com/apache/calcite/pull/260
> DB2 does not support character sets in data type
>
>
> Key: CALCITE-1330
> URL: https://issues.apache.org/jira/browse/CALCITE-1330
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> I have a very small db2 database, and it does not support "varchar(100)
> CHARACTER SET `ISO-8859-1`".
> {code}
> db2 => select TS, cast(TS as varchar(100)) from mydb.mytimestamp
> TS 2
> --
>
> 2016-07-18-01.02.03.00 2016-07-18-01.02.03.00
> 1 record(s) selected.
> {code}
> {code}
> db2 => select TS, cast(TS as varchar(100) CHARACTER SET "ISO-8859-1") from
> mydb.mytimestamp
> SQL0104N An unexpected token "CHARACTER SET "ISO-8859-1"" was found following
> "t(TS as varchar(100)". Expected tokens may include: "".
> SQLSTATE=42601
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1330) DB2 does not support character sets in data type
MinJi Kim created CALCITE-1330:
--
Summary: DB2 does not support character sets in data type
Key: CALCITE-1330
URL: https://issues.apache.org/jira/browse/CALCITE-1330
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
I have a very small db2 database, and it does not support "varchar(100)
CHARACTER SET `ISO-8859-1`".
{code}
db2 => select TS, cast(TS as varchar(100)) from mydb.mytimestamp
TS 2
--
2016-07-18-01.02.03.00 2016-07-18-01.02.03.00
1 record(s) selected.
{code}
{code}
db2 => select TS, cast(TS as varchar(100) CHARACTER SET "ISO-8859-1") from
mydb.mytimestamp
SQL0104N An unexpected token "CHARACTER SET "ISO-8859-1"" was found following
"t(TS as varchar(100)". Expected tokens may include: "".
SQLSTATE=42601
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date, timestamp_diff should handle null dates
[
https://issues.apache.org/jira/browse/CALCITE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373441#comment-15373441
]
MinJi Kim edited comment on CALCITE-1312 at 7/12/16 6:48 PM:
-
Thanks for the review. I made the changes you suggested. Also, while adding
the tests to SqlOperatorBaseTest, I noticed a few other problems (especially in
timestampdiff with null dates). So, I also made those fixes in this patch. I
also updated the jira. Thanks again!
was (Author: minjikim):
Thanks for the review. I made the changes you suggested. Also, while adding
the tests to SqlOperatorBaseTest, I noticed a few other problems (especially in
timestampdiff with null dates). So, I also made those fixes in this patch. I
also updated the jira.
> timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
> than a date, timestamp_diff should handle null dates
>
>
> Key: CALCITE-1312
> URL: https://issues.apache.org/jira/browse/CALCITE-1312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
> returns a date and therefore truncates the minute informtion. timestamp_add
> should return timestamp instead of date for units less than date.
> timestamp_diff with date doesn't handle null properly (in type inference),
> converted type is INTEGER NOT NULL (when it should be null).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date, timestamp_diff should handle null dates
[
https://issues.apache.org/jira/browse/CALCITE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373441#comment-15373441
]
MinJi Kim commented on CALCITE-1312:
Thanks for the review. I made the changes you suggested. Also, while adding
the tests to SqlOperatorBaseTest, I noticed a few other problems (especially in
timestampdiff with null dates). So, I also made those fixes in this patch. I
also updated the jira.
> timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
> than a date, timestamp_diff should handle null dates
>
>
> Key: CALCITE-1312
> URL: https://issues.apache.org/jira/browse/CALCITE-1312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
> returns a date and therefore truncates the minute informtion. timestamp_add
> should return timestamp instead of date for units less than date.
> timestamp_diff with date doesn't handle null properly (in type inference),
> converted type is INTEGER NOT NULL (when it should be null).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date, timestamp_diff should handle null dates
[
https://issues.apache.org/jira/browse/CALCITE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1312:
---
Description:
timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
returns a date and therefore truncates the minute informtion. timestamp_add
should return timestamp instead of date for units less than date.
timestamp_diff with date doesn't handle null properly (in type inference),
converted type is INTEGER NOT NULL (when it should be null).
was:timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
returns a date and therefore truncates the minute informtion. timestamp_add
should return timestamp instead of date for units less than date.
> timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
> than a date, timestamp_diff should handle null dates
>
>
> Key: CALCITE-1312
> URL: https://issues.apache.org/jira/browse/CALCITE-1312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
> returns a date and therefore truncates the minute informtion. timestamp_add
> should return timestamp instead of date for units less than date.
> timestamp_diff with date doesn't handle null properly (in type inference),
> converted type is INTEGER NOT NULL (when it should be null).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date, timestamp_diff should handle null dates
[
https://issues.apache.org/jira/browse/CALCITE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1312:
---
Summary: timestamp_add(UNIT, DATE) should return timestamp if the unit
added is less than a date, timestamp_diff should handle null dates (was:
timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
than a date)
> timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
> than a date, timestamp_diff should handle null dates
>
>
> Key: CALCITE-1312
> URL: https://issues.apache.org/jira/browse/CALCITE-1312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
> returns a date and therefore truncates the minute informtion. timestamp_add
> should return timestamp instead of date for units less than date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1313) expandOrderExpr() does not validate node type and properly set it
[
https://issues.apache.org/jira/browse/CALCITE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371949#comment-15371949
]
MinJi Kim commented on CALCITE-1313:
Thanks for the review! I moved the test case to SqlToRelConverterTest.
> expandOrderExpr() does not validate node type and properly set it
> -
>
> Key: CALCITE-1313
> URL: https://issues.apache.org/jira/browse/CALCITE-1313
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> Queries like the following currently fail in SqlToRelConverter because the
> type in thought to be unknown. Simple fix is to ensure that the type is
> validated when we expand the expression.
> {code}
> java.lang.AssertionError: Parsing failed throwing error: class
> org.apache.calcite.sql.SqlBasicCall: ROW_NUMBER() OVER (PARTITION BY
> `employee`.`store_id` ORDER BY `employee`.`department_id` ROWS BETWEEN
> UNBOUNDED PRECEDING AND CURRENT ROW)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.checkRel2Sql(RelToSqlConverterTest.java:58)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.checkRel2Sql(RelToSqlConverterTest.java:63)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testOver(RelToSqlConverterTest.java:391)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1313) expandOrderExpr() does not validate node type and properly set it
MinJi Kim created CALCITE-1313:
--
Summary: expandOrderExpr() does not validate node type and
properly set it
Key: CALCITE-1313
URL: https://issues.apache.org/jira/browse/CALCITE-1313
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
Queries like the following currently fail in SqlToRelConverter because the type
in thought to be unknown. Simple fix is to ensure that the type is validated
when we expand the expression.
{code}
java.lang.AssertionError: Parsing failed throwing error: class
org.apache.calcite.sql.SqlBasicCall: ROW_NUMBER() OVER (PARTITION BY
`employee`.`store_id` ORDER BY `employee`.`department_id` ROWS BETWEEN
UNBOUNDED PRECEDING AND CURRENT ROW)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.checkRel2Sql(RelToSqlConverterTest.java:58)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.checkRel2Sql(RelToSqlConverterTest.java:63)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testOver(RelToSqlConverterTest.java:391)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date
[
https://issues.apache.org/jira/browse/CALCITE-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371677#comment-15371677
]
MinJi Kim commented on CALCITE-1312:
https://github.com/apache/calcite/pull/253
> timestamp_add(UNIT, DATE) should return timestamp if the unit added is less
> than a date
> ---
>
> Key: CALCITE-1312
> URL: https://issues.apache.org/jira/browse/CALCITE-1312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
> returns a date and therefore truncates the minute informtion. timestamp_add
> should return timestamp instead of date for units less than date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1312) timestamp_add(UNIT, DATE) should return timestamp if the unit added is less than a date
MinJi Kim created CALCITE-1312:
--
Summary: timestamp_add(UNIT, DATE) should return timestamp if the
unit added is less than a date
Key: CALCITE-1312
URL: https://issues.apache.org/jira/browse/CALCITE-1312
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
timestamp_add("MINUTE", 1, date '2016-06-15') returns 2016-06-15 since it
returns a date and therefore truncates the minute informtion. timestamp_add
should return timestamp instead of date for units less than date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
