Robert Haas escribió:
> On Thu, Feb 21, 2013 at 12:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> There's also code to re-obtain the list of objects to drop after the
> >> event trigger functions have run; the second list is compared to the
> >> first one, and if they differ, an error is raised.
> >
> > This is definitely an improvement. I am not 100% clear on whether
> > this is sufficient, but it sure seems a lot better than punting.
>
> What if the object that gets whacked around is one of the named
> objects rather than some dependency thereof? Suppose for example that
> the event trigger drops the same object that the user tried to drop.
> We need to error out cleanly in that case, not blindly proceed with
> the drop.
An error is raised, which I think is sane. I think this peculiar
situation warrants its own few lines in the new regression test.
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.
> (In the worst case, somebody could create an unrelated object with the
> same OID and we could latch onto and drop that one. Seems remote
> unless the user has a way to fiddle with the OID counter, but if it
> happened it would be bad.)
Hmm.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
