On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
