Re: sql_drop Event Trigger

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I thought there was the idea that the list of objects to drop was to be
> acquired before actually doing the deletion; so that the trigger
> function could, for instance, get the name of the table being dropped.
> I don't see that it works if we only provide
> pg_event_trigger_dropped_objects to ddl_command_end events. Am I
> missing something?

Tom and Robert have been rightfully insisting on how delicate it has
been to come up with the right behavior for performMultipleDeletions,
and that's not something we can easily reorganise.

So the only way to get at the information seems to be what Robert
insisted that I do, that is storing the information about the objects
being dropped for later processing.

Of course, later processing means that the objects are already dropped
and that you can't do much. The idea is to provide more than just the
OID of the object, we have yet to decide if adding a catalog cache
lookup within performMultipleDeletions() is ok. If it is, we will extend
the pg_event_trigger_dropped_objects() definition to also return the
object name and its schema name, at a minimum.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support