Re: multi column foreign key for implicitly unique columns

From: Markus Bertheau <twanger(at)bluetwanger(dot)de>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: multi column foreign key for implicitly unique columns
Date: 2004-08-17 15:12:11
Message-ID: 1092755530.2627.36.camel@dicaprio.akademie1.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

В Втр, 17.08.2004, в 17:06, Stephan Szabo пишет:
> On Tue, 17 Aug 2004, Markus Bertheau wrote:
>
> > В Втр, 17.08.2004, в 16:46, Tom Lane пишет:
> >
> > > I think one reason for this is that otherwise it's not clear which
> > > unique constraint the FK constraint depends on. Consider
> > >
> > > create table a (f1 int unique, f2 int unique);
> > >
> > > create table b (f1 int, f2 int,
> > > foreign key (f1,f2) references a(f1,f2));
> > >
> > > How would you decide which constraint to make the FK depend on?
> >
> > Either way, the semantics are the same, right?
>
> Unfortunately, not in the case of dropping the chosen constraint.

Can't you choose at fk check time rather than fk creation time?

> Theoretically in that case, you'd probably have to extend the spec there
> as well to say that you check any dependent objects again to see if they
> would still be valid rather than dropping them (on cascade) or erroring
> (on restrict).

That also makes sense and is more efficient as I see it.

Thanks

--
Markus Bertheau <twanger(at)bluetwanger(dot)de>

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2004-08-17 15:24:18 Re: multi column foreign key for implicitly unique columns
Previous Message Stephan Szabo 2004-08-17 15:09:19 Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo