Re: sql_drop Event Trigger

On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Robert Haas escribió:
>>> I venture to guess that this is exactly the sort of thing that made
>>> Tom argue upthread that we shouldn't be putting a firing point in the
>>> middle of the drop operation. Any slip-ups here will result in
>>> corrupt catalogs, and it's not exactly future-proof either.
>
>> Well, is this kind of thing enough to punt the whole patch, or can we
>> chalk it off as the user's problem?
>
> I don't really think that we want any events in the first release that
> are defined so that a bogus trigger can cause catalog corruption.
> That will, for example, guarantee that we can *never* open up the
> feature to non-superusers. I think we'd be painting ourselves into a
> corner that we could not get out of.

I agree, although my feelings on this point are actually somewhat
stronger than that.

> 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.

> 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.

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