Dimitri Fontaine escribió:
> Alvaro Herrera <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
