Re: sql_drop Event Trigger

Here's an implementation of what we discussed: the event is now DDL_DROP
and is called inside performDeletion and performMultipleDeletions; it
receives the list of objects via pg_dropped_objects (though it now has a
more verbose name), and the objects are still catalogued when the
trigger is called.  This event does *not* receive the parsetree (as
opposed to ddl_command_start/end); also, there's no tag filtering
support, so if you install a function in that event, it will run every
time a DROP of any kind occurs.

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.

There's also code to re-obtain the list of objects to drop after the
event trigger functions have run; the second list is compared to the
first one, and if they differ, an error is raised.

It's rather annoying that performMultipleDeletions and performDeletion
contain almost exactly the same code.  I think maybe it's time to morph
the latter into a thin layer on top of the former.

(small remaiing issue: docs need updated).

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services