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

From David Fetter
Subject Re: Expanding DELETE/UPDATE returning
Date
Msg-id 20070227052445.GD24418@fetter.org
Whole thread Raw
In response to Re: Expanding DELETE/UPDATE returning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Expanding DELETE/UPDATE returning  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-hackers
On Mon, Feb 26, 2007 at 11:14:01PM -0500, Tom Lane wrote:
> Rusty Conover <rconover@infogears.com> writes:
> > I didn't see this on the TODO list, but if it is my apologies.  Is
> > it  in the cards to expand the functionality of DELETE/UPDATE
> > returning  to be able to sort the output of the rows returned?
> 
> No.

Would this be something that windowing functions would need to take
into account?

> > 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.

What kinds of machinery would be needed in order for certain kinds of
subqueries to get executed only once and have the results cached?

<brain_storm>

INSERT/UPDATE/DELETE ... RETURNING wouldn't be the only possible uses
of such machinery.  A data-changing function in a subquery could be
another.  Maybe there could be some way to mark functions as "execute
once per subquery."

</>

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Dead Space Map version 2
Next
From: "Jim C. Nasby"
Date:
Subject: Re: autovacuum next steps, take 2