Horton

Re: Command Triggers, patch v11

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>
Date: 2012-03-16T21:37:38Z
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 Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > One more thing I disliked quite a bit was the duplication of the EXECUTE
> > handling. Do you see a way to deduplicate that?
> Yeah, that's what's bugging me, too.  I think a chunk of the problem is
> that you're insisting on having control come back to CreateTableAs()
> to perform the table creation.  I'm thinking that if the table creation
> were to be moved into the tuple receiver's startup routine, we could
> avoid needing to get control back between ExecutorStartup and
> ExecutorRun, and then all that would be required would be to call
> ExecuteQuery with a different DestReceiver.
Hm. I seriously dislike doing that in the receiver. I can't really point out 
why though. Unsurprisingly I like getting the control back to CreateTableAs...

Andres