Horton

Re: Command Triggers, patch v11

Tom Lane <tgl@sss.pgh.pa.us>

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

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.

			regards, tom lane