Re: foreign key constraints referencing inherited relations - WIP - Mailing list pgsql-patches

From Tom Lane
Subject Re: foreign key constraints referencing inherited relations - WIP
Date
Msg-id 12952.1131666259@sss.pgh.pa.us
Whole thread Raw
In response to foreign key constraints referencing inherited relations - WIP  (Matt Newell <newellm@blur.com>)
List pgsql-patches
Matt Newell <newellm@blur.com> writes:
> When removing the ONLY clause on the foreign key checks, I also had to remove
> the FOR SHARE OF x part.  This was in the following functions: RI_FKey_check,
> ri_Check_Pk_Match, RI_FKey_noaction_del, RI_FKey_noaction_upd,
> RI_FKey_restrict_del. I don't really understand the significance of this.

It means you broke it for concurrent-update cases; there's no interlock
preventing someone from dropping the PK row after you look at it
and before you commit the referencing row.

> Inherited relations don't share primary key indexes, so there is the
> possibility of duplicates.

Which means the whole thing doesn't work, really.  Without a uniqueness
constraint across the set of PK rows, the semantics of FK constraints
are not well-defined.  The multi-table-unique-constraint problem has to
be solved before we can even think much about multi-table FKs :-(

Without having read the patch in detail, I'm guessing that what you've
done might allow the referencing side of an FK constraint to be
inherited (since all this takes is copying down the triggers to the
child tables), but the referenced side still has to be a single table.

            regards, tom lane

pgsql-patches by date:

Previous
From: Matt Newell
Date:
Subject: foreign key constraints referencing inherited relations - WIP
Next
From: "Hiroshi Saito"
Date:
Subject: problem in MS-VC6 environment.