Re: UPDATE using sub selects - Mailing list pgsql-patches

From Tom Lane
Subject Re: UPDATE using sub selects
Date
Msg-id 407.1205793649@sss.pgh.pa.us
Whole thread Raw
In response to Re: UPDATE using sub selects  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UPDATE using sub selects  (NikhilS <nikkhils@gmail.com>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: UPDATE using sub selects
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Proposal: new large object API