From: | Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com> |
---|---|
To: | Alban Hertroys <haramrae(at)gmail(dot)com> |
Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Foreign keys question (performance) |
Date: | 2011-12-04 11:41:39 |
Message-ID: | CAFWfU=tNz63sZQf=LJJWjzqrDJx6rx=8XkOuJSj8rVZ6FRcRYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Dec 4, 2011 at 7:14 PM, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
> On 4 Dec 2011, at 11:19, Phoenix Kiula wrote:
....
>
> INSERTs in the parent table don't need to check for any reference from the child table, since they're new; there can't be a reference. UPDATEs and DELETEs do though, whether you let them CASCADE or not. If you don't, then the database raises a foreign key constraint violation. If you do, then it needs to modify the relevant rows in the child table.
>
> Likewise, INSERTs and UPDATEs in the child table need to verify that - if their reference key changed - they're still referencing a valid row.
Thanks Albert. Very useful.
I had ON DELETE...ALSO DELETE rules earlier and in some cases they let
some keys go by in associated tables. Hope foreign key constraint is
more reliable!
PK
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2011-12-04 11:51:00 | Re: Weird behavior: deleted row still in index? |
Previous Message | Phoenix Kiula | 2011-12-04 11:32:33 | Weird behavior: deleted row still in index? |