Re: Command Triggers, patch v11

On 3 March 2012 16:12, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> 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.

Don't you mean "shouldn't need to specify more than the trigger name"?

--
Thom