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>
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 |