On 3 March 2012 16:12, Kevin Grittner <kevin.gritt...@wicourts.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
