On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> 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.
Definitely. > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
