Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
