Horton

Re: Command Triggers, patch v11

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>
Date: 2012-03-19T16:52:00Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

  2. Remove useless const qualifier

  3. Make executor's SELECT INTO code save and restore original tuple receiver.

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