[
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896833#comment-16896833
]
Pressenna edited comment on CALCITE-3186 at 7/31/19 7:08 AM:
-------------------------------------------------------------
It's more then a refactoring.
Before I would scan the entire {{UDAPTE}} 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.
was (Author: psockali):
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)
