On Fri, Dec 14, 2012 at 2:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Dec 13, 2012 at 6:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I suspect there are still ways to shoot yourself in the foot with a >>> broken event trigger, but it's not quite as trivial as I thought. > >> I'm smart enough not to doubt you, but I'd sure appreciate a hint as >> to what you're worried about before we start building more on top of >> it. I don't want to sink a lot of work into follow-on commits and >> then discover during beta we have to rip it all out or disable it. It >> seems to me that if you can always drop an event trigger without >> interference from the event trigger system, you should at least be >> able to shut it off if you don't like what it's doing. > > I doubt that not firing on DROP EVENT TRIGGER, per se, will be > sufficient to guarantee that you can execute such a drop. Even > if that's true in the current state of the code, we're already > hearing requests for event triggers on lower-level events, eg > http://archives.postgresql.org/pgsql-hackers/2012-12/msg00314.php
Yep, true. > Sooner or later there will be one somewhere in the code path involved > in doing a heap_delete on pg_event_trigger, or one of the subsidiary > catalogs such as pg_depend, or maybe one that just manages to fire > someplace during backend startup, or who knows what. Yeah. :-( > Hence, I want a kill switch for all event triggers that will most > certainly work, and the just-committed patch provides one. I'm definitely not disputing the need for that patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
