On Thu, Feb 10, 2011 at 12:03:49AM -0500, Tom Lane wrote: > strk <s...@keybit.net> writes: > > I've finally completed the debugging phase and have > > a minimal self-contained testcase showing the problem. > > It has to do with INITIALLY DEFERRED constraints. > > I looked into this and find that the issue is you're trying to drop a > table that has unfired AFTER TRIGGER events pending. When they finally > fire, they can't find the table anymore. > > I'm inclined to think that we should disallow that; or even more to the > point, that it'd be a good thing to apply CheckTableNotInUse() when > about to drop a table. If we disallow such cases for ALTER TABLE, then > a fortiori we should do so for DROP TABLE. > > Aside from disallowing unfired trigger events, CheckTableNotInUse would > disallow the table being actively relation_open'd by any operation. > This seems like a real good thing anyway (imagine, eg, DROP TABLE > executed from a trigger for that table).
+1. We even do it for TRUNCATE, so surely it's proper for DROP. > It's possible that we could handle the unfired-trigger problem by > marking the relevant events AFTER_TRIGGER_DONE, but I'm unconvinced that > it's worth spending effort on. Seems rare enough not to worry much about, particularly considering the SET CONSTRAINTS escape hatch. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
