Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Robert Haas escribi�:
>> It seems to me that a better way to do this might be to look up the
>> names of all the objects being dropped, as we get rid of them, and
>> pass that information off to the ddl_command_end trigger via something
>> like the pg_dropped_objects() function Dimitri proposed. Then we
>> don't have to deal with the massive grottiness of running a command
>> right in the middle of the deletions, which I continue to maintain
>> will have many as-yet-unforeseen failure modes.
I share Robert's fear of this.
> There are two points you're making here: one is about what data do we
> provide about objects being dropped (you argue OIDs and names are
> sufficient); and you're also saying calling these triggers at
> ddl_command_end is the right timing. I disagree about the first one,
> because I don't think object names are sufficient; Tom argued upthread
> about being able to look up the objects from the catalogs in the event
> trigger function. This in turn means that ddl_command_end is not good
> enough; these functions need to be called earlier than that. Which is
> what the new DDL_DROP event provides: a point in the execution sequence
> that's after we've looked up the objects, but before they are gone from
> the catalogs.
> Can we get agreement on those points? Otherwise ISTM we're going to
> continue to argue in circles.
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these inescapable
facts, and I'm not sure if we can get consensus on that.
On the whole, though, I'm thinking that the approach Robert suggests
is the way to go, because it doesn't foreclose our doing something
else later. Whereas if we ship 9.3 with a mid-DROP event, and we then
find out that it's even more dangerous than we currently realize,
we're going to be between a rock and a hard place.
regards, tom lane
