Re: Foreign key problem

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Itai Zukerman <zukerman(at)math-hat(dot)com>
Cc: Andreas Tille <tillea(at)rki(dot)de>, PostgreSQL SQL <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Foreign key problem
Date: 2001-06-25 16:22:56
Message-ID: Pine.BSF.4.21.0106250917410.22309-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On 25 Jun 2001, Itai Zukerman wrote:

> According to the documentation for CREATE TABLE:
>
> In addition, the referenced columns are supposed to be the columns
> of a UNIQUE constraint in the referenced table, however Postgres
> does not enforce this.
>
> Well, it looks like PostgreSQL *does* enforce it. Try it with:

Hmm, that paragraph should have been ripped out at the same time I added
the check. Will see if I need to patch the docs (or if it was already
done by someone).

> CREATE UNIQUE INDEX IX_IdLabNr_KulturDetail
> ON ResKulturDetail(IdLabNr, IdIndex) ;
>
> I'm not sure why this restriction is necessary...

Mostly because the semantics of the constraint as defined by the spec
don't make sense in certain cases against non-unique pk table rows. For
example, a delete cascade would delete the *first* time a matched row was
deleted even if there were other rows that could be matched except in
MATCH PARTIAL (which we don't support). Once we support MATCH PARTIAL,
we might make the case to allow MATCH PARTIAL references to non-unique
columns as an extension, but we'd need to think through the other effects
of that.

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Wei Weng 2001-06-25 17:19:45 control structure in a transaction block?
Previous Message Luis Sousa 2001-06-25 15:08:44 Problems using a rule with the WHERE clause