Hi Tom,
> ... eg backend/nodes/, optimizer/util/clauses.c, ruleutils.c...)
Actually, on further thought ruleutils.c represents one of the biggest
stumbling blocks here. We have to be able to reverse-compile the parse
tree into something that's at least semantically equivalent to the
original query. The existing kluge for UPDATE SET (columns) = ... can
ignore this because it rearranges the query into a sematically
equivalent update with independent SET targets, but the whole problem
with sub-select updates is that there *is* no semantically equivalent
command with a flat targetlist. So one way or another there will have
to be more information in the parse tree than there is now.
If we use Params that can be traced back to specific SubLink list
entries, it might be okay to finesse this by having ruleutils.c check
for successive targetlist entries that reference outputs of the same
SubLink. That's pretty ugly but it might be better than changing the
representation of targetlists, which is something that's understood
by one heck of a lot of code.
Thanks a lot for taking a look at this patch. As mentioned and detailed out by you, this patch *does* need a lot more amount of work and is certainly not a simpler effort that I had envisioned it to be earlier. Another issue with the patch as it stands today is that it does not work with correlated subqueries. This will require some more work too. So for example, something of this sort does not work yet:
UPDATE update_tbl set (a, b) = (select a, b from other_tbl where c = update_tbl.c) where a = 10;
I will try to have another shot at it if I can, before the next commit fest.
Thanks and Regards,
Nikhils
--
EnterpriseDB
http://www.enterprisedb.com
