Re: Command Triggers, patch v11

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Kevin Grittner <Kevin.Grittner@wicourts.gov>

Cc: Thom Brown <thom@linux.com>, Tom Lane <tgl@sss.pgh.pa.us>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2012-03-03T00:12:46Z

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 Tue, Feb 28, 2012 at 10:09 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This seems over-complicated.  Triggers on tables do not have
>> alterable properties, why should command triggers?  I vote for
>>
>>       CREATE COMMAND TRIGGER name ... properties ...;
>>
>>       DROP COMMAND TRIGGER name;
>>
>> full stop.  If you want to run the same trigger function on some
>> more commands, add another trigger name.
>
> +1

+1.  I suggested the same thing a while back.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company