[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions

2019-10-03 Thread Pressenna (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944146#comment-16944146
 ] 

Pressenna commented on CALCITE-3186:


thank you.

> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this 
> side-effect.
>  
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>  
> These seem to raise exceptions now.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions

2019-10-03 Thread Haisheng Yuan (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944088#comment-16944088
 ] 

Haisheng Yuan commented on CALCITE-3186:


It has been fixed in 1.21.0, by commit 
https://github.com/apache/calcite/commit/b8d24a6f7f2b4c7cb8093eea158f1fa00dbc6ffc.

> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this 
> side-effect.
>  
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>  
> These seem to raise exceptions now.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions

2019-07-31 Thread Pressenna (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896833#comment-16896833
 ] 

Pressenna commented on CALCITE-3186:


It's more then a refactoring. 

Before I would scan the entire query for expandable expression, now doing this 
only for the source expression lists.
This should be sufficient for UPDATE statements, because the subsequent call to 
{{convertSelectImpl()}} scans the {{SelectSource}} query as well for expandable 
expressions.

The added test cases also show that  {{ WHERE field IN (10,11) }} now works 
without raising an exception.


> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this 
> side-effect.
>  
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>  
> These seem to raise exceptions now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions

2019-07-30 Thread Danny Chan (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896801#comment-16896801
 ] 

Danny Chan commented on CALCITE-3186:
-

It seems that the original failure is because you use the `TEXT` data type 
which does not have any internal implementation in Calcite core, i'm a little 
confused why the PR can fix this problem. The PR itself seems a code refactor ~

> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this 
> side-effect.
>  
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>  
> These seem to raise exceptions now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions

2019-07-29 Thread Pressenna (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895756#comment-16895756
 ] 

Pressenna commented on CALCITE-3186:


[~danny0405], I created a PR with a test case and a fix for the immediate 
problem.


> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this 
> side-effect.
>  
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>  
> These seem to raise exceptions now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)