Robert Haas escribió:
> On Wed, Feb 20, 2013 at 10:48 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > I have added some protections so that these do not fire on undesirable
> > events (such as dropping an event trigger); also event triggers and
> > other object types are filtered out of pg_dropped_objects, in case
> > something like DROP OWNED happens. (So for instance you could get an
> > empty pg_dropped_objects if you did DROP OWNED and the mentioned user
> > only owns an event trigger). Maybe this needs to be reconsidered.
>
> This is tricky. The whole point of skipping the
> ddl_command_start/ddl_command_end triggers when the command is one
> that operates on event triggers is that we don't want a user to
> install an event trigger that prevents said user from dropping that
> event trigger afterwards. We're currently safe from that, but with
> the behavior you describe, we won't be: an event trigger that
> unconditionally thows an error will block all drops, even of event
> triggers.
You're misunderstanding. If you do DROP EVENT TRIGGER, the DDL_DROP
event won't fire at all. So no matter how messed up your system is, you
can always fix it by simply dropping the event trigger.
What I was saying is that if you have some command other than DROP EVENT
TRIGGER, which happens to drop an event trigger, said event trigger will
not be present in the pg_dropped_objects results.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
