On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane <tgl@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