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). ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend