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
>> +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:

Reply via email to