Re: Command Triggers, patch v11

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

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

Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>

Date: 2012-03-17T18:16:26Z

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 →

Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.
- b4af1c25bbc6 9.2.0 cited
Remove useless const qualifier
- 66f0cf7da8ee 9.2.0 cited
Make executor's SELECT INTO code save and restore original tuple receiver.
- dfd26f9c5f37 9.2.0 cited

On Saturday, March 17, 2012 06:45:27 PM Tom Lane wrote:
> I'm not sure that anybody cares about being able to fire command
> triggers on DECLARE CURSOR
I actually think it would make sense to explicitly not fire command triggers 
there given that DECLARE CURSOR actually potentially is somewhat performance 
relevant.

> , but just from a consistency standpoint it
> would make sense for this to work more like EXPLAIN and CREATE TABLE AS.
> So that convinces me that UtilityContainsQuery() would be a good thing,
> and I'll add that to the patch.  (Actually changing DECLARE CURSOR seems
> like a separate patch, though.)
Aggreed on that.

Andres