> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
