Re: sql_drop Event Trigger

Robert Haas escribió:
> On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:

> > One funny thing I noticed is that if I add a column in a table being
> > dropped, the targetObjects list does not change after the trigger has
> > run. The reason for this is that the table's attributes are not present
> > in the targetObjects list; instead they are dropped manually by calling
> > DeleteAttributeTuples(). I saw that you can end up with lingering
> > pg_attribute entries that way.
>
> 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? We can word the docs to state that
we try to detect actions that are known to cause corruption but that
some might slip past, and that it's the user's responsibility to ensure
that the event trigger functions behave sanely.

Another idea I just had was to scan the catalogs after the event trigger
and see if the Xmin for each tuple IsCurrentTransaction(), and if so
throw an error. I think that would be more accurate than the current
implementation, but rather a lot of trouble. I'm open to implementing
that if we consider that idea watertight enough that this patch is
considered commitable.

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