Re: Expanding DELETE/UPDATE returning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Expanding DELETE/UPDATE returning
Date
Msg-id 11996.1172554257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Expanding DELETE/UPDATE returning  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> writes:
> On Mon, Feb 26, 2007 at 11:14:01PM -0500, Tom Lane wrote:
>> Rusty Conover <rconover@infogears.com> writes:
>>> Or allow delete and update to be used in sub-queries?
>> 
>> That's been discussed but the implementation effort seems far from
>> trivial.  One big problem is that a sub-query can normally be
>> re-executed multiple times, eg on the inner side of a join; whereas
>> that's clearly not acceptable for an insert/update/delete.

> Couldn't we avoid that by writing the data to a tuplestore? Or is it too
> hard to detect the cases when that would need to happen?

I said it wasn't trivial, not that it wasn't doable.  Offhand I think
you'd need a tuplestore buffer, plus a major refactoring of the executor
toplevel --- because currently, all types of updating queries are
hardwired for the actual update to occur only at top level.  There are
also some definitional issues: when do you think triggers should fire?
What happens if the outer query contains a LIMIT clause that a naive
user would think causes the updating subquery not to be read all the way
to the end?  If there are multiple updating subqueries in the same outer
query, how do they interact?

I don't say it's insoluble, just not trivial ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: autovacuum next steps, take 2
Next
From: Tom Lane
Date:
Subject: Re: autovacuum next steps, take 2