Re: Command Triggers, patch v11

Thom Brown <thom@linux.com>

From: Thom Brown <thom@linux.com>

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

Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2012-02-28T15:14:29Z

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 28 February 2012 15:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thom Brown <thom@linux.com> writes:
>> Well the problem is that you can add commands to a trigger en masse,
>> but you can only remove them one at a time.  Couldn't we at least
>> allow the removal of multiple commands at the same time?  The docs you
>> wrote suggest you can do this, but you can't.
>
> 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.

This would make more sense, particularly since dropping a command
trigger, as it stands, doesn't necessarily drop the trigger.

-- 
Thom