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? > > 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 <[EMAIL PROTECTED]> 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 ---------------------------(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 match
