Re: sql_drop Event Trigger

Robert Haas escribió:
> On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:

> > Maybe down the road we'll conclude that there's no other way and we're
> > willing to put up with an unsafe feature, but I don't want to take that
> > step under time pressure to ship something in 9.3.
>
> I'm opposed to doing it under any circumstances, ever.  Right now,
> there's a very limited number of things which can result in foreign
> key constraints between system catalogs being violated.  So, when it
> happens, from a support point of view, we don't have many things to
> investigate.  If we add "badly written event triggers" to the list,
> it's going to open up a can of worms so large it'll be gravitationally
> rounded.

Well, that's a good point, but I think that was a foreseeable
consequence of event triggers themselves.  I agree that we need to get
this as robust and bulletproof as possible.

> > I thought the proposal was to recompute the set of drop target objects,
> > and complain if that had changed.
>
> Alvaro did that, but it isn't sufficient to prevent catalog corruption.
>
> 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.

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.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services