On Mon, Feb 26, 2007 at 11:14:01PM -0500, Tom Lane wrote:
> Rusty Conover <[EMAIL PROTECTED]> 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?
Would this be something that windowing functions would need to take
> > 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?
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."
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not