Dimitri Fontaine escribió: > 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.
Well, I don't necessarily suggest that. But how about something like this in performMultipleDeletions: /* * Fire event triggers for all objects to be dropped */ if (EventTriggerSQLDropInProgress) { for (i = 0; i < targetObjects->numrefs; i++) { ObjectAddress *thisobj; thisobj = targetObjects->refs + i; if (EventTriggerSQLDropInProgress && EventTriggerSupportsObjectType(getObjectClass(thisobj))) { add_exact_object_address(thisobj, EventTriggerSQLDropList); } } /* invoke sql_drop triggers */ EventTriggerSQLDrop(); /* EventTriggerSQLDropList remains set for ddl_command_end triggers */ } /* and delete them */ for (i = 0; i < targetObjects->numrefs; i++) { ObjectAddress *thisobj; thisobj = targetObjects->refs + i; deleteOneObject(thisobj, &depRel, flags); } -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers