pg.ddx.io pgsql-sql@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Markus Bertheau <twanger@bluetwanger.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Huxton <dev@archonet.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: multi column foreign key for implicitly unique columns
Date: Tue, 17 Aug 2004 08:24:18 -0700 (PDT)
Message-ID: <20040817081306.J61699@megazone.bigpanda.com> (raw)
In-Reply-To: <1092755530.2627.36.camel@dicaprio.akademie1.de>
References: <1092734724.2627.4.camel@dicaprio.akademie1.de>
<4121D55D.1040105@archonet.com>
<20040817072443.S60684@megazone.bigpanda.com>
<4307.1092753995@sss.pgh.pa.us>
<1092754658.2627.32.camel@dicaprio.akademie1.de>
<20040817080425.U61699@megazone.bigpanda.com>
<1092755530.2627.36.camel@dicaprio.akademie1.de>
On Tue, 17 Aug 2004, Markus Bertheau wrote:
> Ð ÐÑÑ, 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.
I'm not seeing what you're seeing then.
Right now, at creation, we can say object A depends on object B. When you
go to drop object B, we can easily lookup up which objects (A) depend on
it. When you go to drop object C, we can easily lookup up which objects
() depend on it.
If instead you put it off to drop time, when you drop object B, you need
to figure out which objects might potentially depend on be (lets say
(A,C)) and then determine which objects those do depend on and see if B is
among those sets.
If we do the in-between one, we could say that object A partially depends
on B (because something else can fufill the requirement as well
potentially). When you go to drop object B, we can see that A partially
depends on B and then check only A's dependencies to see whether any other
thing that might fufill the requirement still exists. In general, such a
system would need to be able to make sure that it worked properly with
multiple concurrent drops of objects that an object partially dependended
on (even though the constraint case is probably safe.) It sounds like
it'd be a pain at best.
view thread (38+ messages) latest in thread
Message-ID: <20040817081306.J61699@megazone.bigpanda.com> Permalink: ../20040817081306.J61699@megazone.bigpanda.com/ Also on: postgresql.org/message-id/20040817081306.J61699@megazone.bigpanda.com ·
reply
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Reply to all the recipients using the --to and --cc options: reply via email To: pgsql-sql@postgresql.org Cc: sszabo@megazone.bigpanda.com, twanger@bluetwanger.de, tgl@sss.pgh.pa.us, dev@archonet.com Subject: Re: multi column foreign key for implicitly unique columns In-Reply-To: <20040817081306.J61699@megazone.bigpanda.com> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox