I wrote: > ... 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. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches