From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FKey not enforced resulting in broken Dump/Reload |
Date: | 2013-07-19 18:15:53 |
Message-ID: | CA+TgmoZBNT_fdG2_pw4Qhzm7LQEJCwUZj7FmcyN_sJGQUrqS8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor <rod(dot)taylor(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-07-19 18:27:17 | Re: FKey not enforced resulting in broken Dump/Reload |
Previous Message | Greg Stark | 2013-07-19 17:50:10 | Re: Review: UNNEST (and other functions) WITH ORDINALITY |