Horton

Re: Command Triggers, patch v11

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
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-18T19:12:03Z
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.

Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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?)

That lights a bulb: what about rewriting CREATE TABLE AS as two
commands, internally:

 1. CREATE TABLE …
 2. WITH x ( <query here> ) INSERT INTO … SELECT * FROM x;

It seems like not solving much from a practical point of view though as
you need to be able to parse the output of the subquery before you can
do the first step, but on the other hand it might be that you already
have the pieces to just do that.

Well, I had to share that though, somehow.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support