Subject: Re: multi column foreign key for implicitly unique columns
From: Markus Bertheau <twanger@bluetwanger.de>
To: Josh Berkus <josh@agliodbs.com>
Cc: olly@lfix.co.uk, pgsql-sql@postgresql.org
In-Reply-To: <200408171945.15663.josh@agliodbs.com>
References: <1092734724.2627.4.camel@dicaprio.akademie1.de>
	<1092735576.28365.48.camel@linda>
	<1092736197.2627.12.camel@dicaprio.akademie1.de>
	<200408171945.15663.josh@agliodbs.com>
Content-Type: text/plain; charset=UTF-8
Message-Id: <1092808820.2728.27.camel@teetnang>
Mime-Version: 1.0
Date: Wed, 18 Aug 2004 08:00:21 +0200
Content-Transfer-Encoding: quoted-printable

=D0=92 =D0=A1=D1=80=D0=B4, 18.08.2004, =D0=B2 04:45, Josh Berkus =D0=BF=D0=
=B8=D1=88=D0=B5=D1=82:
> Markus,

Hi Josh,

> Hey, I see you figured out a workaround to writing a trigger for this.  L=
et's=20
> see if we can make it work.
>=20
> ERROR:  there is no unique constraint matching given keys
>         for referenced table "objects"
>=20
> The reason for this is that CASCADE behavior gets quite odd when there is=
 an=20
> FK reference to a non-unique column.   We used to allow it, in 7.1, and I=
 was=20
> responsible for a number of bug reports that led to us disallowing it.   =
It=20
> should be theoretically implementable and relationally sound but will req=
uire=20
> a *lot* of troubleshooting to make work.   So far, nobody's really intere=
sted=20
> enough.
>=20
> However, you have an easy way out:
>=20
> ALTER TABLE objects ADD CONSTRAINT obj_unq_2 UNIQUE (name, class_name);

I was worried about the performance hit because (name, class_name) will
always be unique, yet they will be checked for uniqueness.

Thanks

--=20
Markus Bertheau <twanger@bluetwanger.de>