From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rusty Conover <rconover(at)infogears(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Expanding DELETE/UPDATE returning |
Date: | 2007-02-27 05:12:44 |
Message-ID: | 20070227051244.GL29041@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 26, 2007 at 11:14:01PM -0500, Tom Lane wrote:
> Rusty Conover <rconover(at)infogears(dot)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.
>
> > 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?
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-02-27 05:24:45 | Re: Expanding DELETE/UPDATE returning |
Previous Message | Jim C. Nasby | 2007-02-27 05:11:44 | Re: Dead Space Map version 2 |