Robert Haas escribió: > On Thu, Feb 21, 2013 at 12:25 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
