From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed feature: Selective Foreign Keys |
Date: | 2013-12-03 22:57:57 |
Message-ID: | CAPPfruzZDmfLKxSB=mMEU7qb3xLaQQkqQ+eD8nXpTZGQ-pPzfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4 December 2013 01:24, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yeah, more or less, but the key is ensuring that it wouldn't let you
> create the constraint in the first place if the partial index
> specified *didn't* match the WHERE clause. For example, suppose the
> partial index says WHERE parent_entity = 'event' but the constraint
> definition is WHERE parent_event = 'somethingelse'. That ought to
> fail, just as creating a regular foreign constraint will fail if
> there's no matching unique index.
The where clause only applies to queries against the FK table, and we
don’t currently fail if there isn’t a matching index on the fk column
when creating a FK (I’ve been bitten by that before).
We fail if there isn’t a unique index on the referenced
table/column(s), but queries against that table on insert/update not
the FK table are unchanged (save that we don’t bother with them at all
if the where clause expression fails for the given tuple).
Cheers
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Timothy Garnett | 2013-12-03 22:58:12 | Re: Allowing parallel pg_restore from pipe |
Previous Message | Alvaro Herrera | 2013-12-03 22:55:40 | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |