Re: Use of systable_beginscan_ordered in event trigger patch

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 13, 2012 at 6:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

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.

Hence, I want a kill switch for all event triggers that will most
certainly work, and the just-committed patch provides one.

regards, tom lane