Re: Command Triggers, patch v11

> Thom Brown  wrote:
> Dimitri Fontaine  wrote:
>> Thom Brown  writes:
>>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>>> comment, as it makes more sense to drop the entire trigger than
>>> individual commands for that trigger.
>>
>> What you're saying here is that a single command could have more
>> than one command attached to it, and what I understand Tom, Robert
>> and Kevin are saying is that any given command trigger should only
>> be attached to a single command.
> 
> I hadn't interpreted it that way
Nor had I.
> I'm still of the opinion that a single command trigger should be
able to attach to multiple commands, just not
> amendable once the trigger has been created.
That was my understanding of what we were discussing, too.
> So my vote was for:
> 
> CREATE COMMAND TRIGGER name { BEFORE | AFTER } command [, ... ]
> EXECUTE PROCEDURE function_name ()
> 
> ALTER COMMAND TRIGGER name SET enabled
> 
> DROP COMMAND TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]
Same here.
> My argument for this is that you may wish to implement the same
> trigger for tables, views and foreign tables rather than create 3
> separate triggers.
Right.  What I thought I was agreeing with was the notion that you
should need to specify more than the trigger name to drop the
trigger.  Rather like how you can create a trigger AFTER INSERT OR
UPDATE OR DELETE, but you don't need to specify all those events to
drop the trigger -- just the name will do.
-Kevin