On 3 March 2012 19:25, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > "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.
That sucks. I'm surprised there's no provision for overriding it on a command-by-command basis. I would suggest an array instead, but that sounds costly from a look-up perspective. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
