On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor <rod.taylor@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
