Re: sql_drop Event Trigger - Mailing list pgsql-hackers

On Wed, Feb 6, 2013 at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> Alvaro Herrera <alvherre@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.
>
>> 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.
>
> I might be forgetting something, but doesn't dependency.c work by first
> constructing a list of all the objects it's going to drop, and only then
> dropping them?  Could we inject a "pre deletion" event trigger call at
> the point where the list is completed?

In theory, sure, but in practice, there are multiple ways that can
break things.  The possibility that the event trigger that runs at
that point might drop one of the objects involved has already been
mentioned, but there are others.  For example, it might *create* a new
object that depends on one of the objects to be dropped, potentially
leading to an inconsistent pg_depend.  It could also ALTER the object,
or something that the object depends on.  For example, suppose we're
running an event trigger in the middle of a DROP TABLE command, and
the event trigger creates a _SELECT rule on the table, transforming it
into a view.  Or, suppose it opens (and leaves open) a cursor scanning
that table (normally, CheckTableNotInUse prevents that, but here we've
already done that).  Alternatively, suppose we're dropping a view
which the event trigger redefines to depend on a completely different
set of objects.

I don't deny that code can be written to handle all of those cases
correctly.  But it's going to be a major refactoring, and the idea
that we should be starting to design it in February seems ludicrous to
me.  It'll be May by the time we get this one patch right.  Of 2014.
And there are more than 70 other patches that need attention in this
CommitFest.  I have thus far mostly avoided getting sucked into the
annual argument about which things should be evicted from this
CommitFest because, frankly, I have better things to do with my time
than argue about what the feature freeze date is with people who
should know better.  But the problem isn't going to go away because we
don't talk about it.  Has anyone else noticed that "final triage" is
scheduled to end tomorrow, and we haven't done any triage of any kind
and, at least with respect to this feature, are effectively still
receiving new patch submissions?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company