From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Markus Bertheau <twanger(at)bluetwanger(dot)de> |
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:06:05 |
Message-ID: | 20040817080425.U61699@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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.
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).
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-08-17 15:09:19 | Re: SELECT MAX(c) FROM (SELECT ... FOR UPDATE) AS foo |
Previous Message | Markus Bertheau | 2004-08-17 14:57:38 | Re: multi column foreign key for implicitly unique columns |