On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor <rod.tay...@gmail.com> wrote: >>> A poorly coded trigger on the referencing table has the ability to break >>> foreign keys, and as a result create a database which cannot be dumped and >>> reloaded. > >> This is a known limitation of our foreign key machinery. It might >> well be susceptible to improvement, but I wouldn't count on anyone >> rewriting it in the near future. > > If we failed to fire triggers on foreign-key actions, that would not be > an improvement. And trying to circumscribe the trigger's behavior so > that it couldn't break the FK would be (a) quite expensive, and > (b) subject to the halting problem, unless perhaps you circumscribed > it so narrowly as to break a lot of useful trigger behaviors. Thus, > there's basically no alternative that's better than "so don't do that".
I think a lot of people would be happier if foreign keys were always checked after all regular triggers and couldn't be disabled. But, eh, that's not how it works. -- 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
