On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so >>> that it can enforce that the prepared query is a SELECT. (BTW, maybe >>> this should be weakened to "something that returns tuples", in view of >>> RETURNING?) > >> +1 for "something that returns with tuples". CREATE TABLE ... AS >> DELETE FROM ... WHERE ... RETURNING ... seems like a cool thing to >> support. > > For the moment I've backed off that idea. The main definitional > question we'd have to resolve is whether we want to allow WITH NO DATA, > and if so what does that mean (should the DELETE execute, or not?). > I am also not certain that the RETURNING code paths would cope with > a WITH OIDS specification, and there are some other things that would > need fixed. It might be cool to do it sometime, but it's not going to > happen in this patch.
Fair enough. It would be nice to have, but it definitely does not seem worth spending a lot of time on right now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
