X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 2997B5E46F5
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed, 18 Aug 2004 13:18:52 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 44763-10
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed, 18 Aug 2004 16:18:56 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id E2D895E46E2
	for <pgsql-sql@postgresql.org>; Wed, 18 Aug 2004 13:18:48 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i7IGIbcX001536;
	Wed, 18 Aug 2004 12:18:37 -0400 (EDT)
To: Richard Huxton <dev@archonet.com>
Cc: Jan Wieck <JanWieck@Yahoo.com>, Markus Bertheau <twanger@bluetwanger.de>,
	Josh Berkus <josh@agliodbs.com>, olly@lfix.co.uk,
	pgsql-sql@postgresql.org, Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: multi column foreign key for implicitly unique columns 
In-reply-to: <41237DA2.9090405@archonet.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> <41235A90.1080300@Yahoo.com>
	<1092836961.2630.3.camel@dicaprio.akademie1.de>
	<41236277.5060903@Yahoo.com> <22808.1092842209@sss.pgh.pa.us>
	<41237DA2.9090405@archonet.com>
Comments: In-reply-to Richard Huxton <dev@archonet.com>
	message dated "Wed, 18 Aug 2004 17:02:42 +0100"
Date: Wed, 18 Aug 2004 12:18:37 -0400
Message-ID: <1535.1092845917@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200408/201
X-Sequence-Number: 18698

Richard Huxton <dev@archonet.com> writes:
> * Allow multiple unique constraints to share an index where one is a 
> superset of the others' columns.

> That way you can mark it unique without having the overhead of multiple 
> indexes.

That just moves the uncertain-dependency problem over one spot, ie, it's
the fabricated unique constraint that you can't pin down the
requirements for.

			regards, tom lane