"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > 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.
The parallel between INSERT/UPDATE/DELETE and the trigger's command is not working well enough, because in the data trigger case we're managing a single catalog entry with a single command, and in the command trigger case, in my model at least, we would be managing several catalog entries per command. To take an example: CREATE COMMAND TRIGGER foo AFTER create table, create view; DROP COMMAND TRIGGER foo; The first command would create two catalog entries, and the second one would delete the same two entries. It used to work this way in the patch, then when merging with the new remove object infrastructure I lost that ability. From the beginning Robert has been saying he didn't want that behavior, and Tom is now saying the same, IIUC. So we're back to one command, one catalog entry. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
