Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Subject: Re: Constraint problem
Date: Thu, 16 May 2002 13:49:18 -0700
Cc: <pgsql-sql@postgresql.org>
References: <20020516132750.P93696-100000@megazone23.bigpanda.com>
In-Reply-To: <20020516132750.P93696-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200205161349.18499.josh@agliodbs.com>


Stephan,

> I unfortunately can't think of a good workaround. AFAICT, Unique should
> wait until after all of the updates but our implementation doesn't
> currently do so.
>=20
> Hopefully someone will have some ideas, because the best I can think of
> requires an additional full table scan to check uniqueness and the
> concurrency issues would be a bear.

Hmm ... I can put up with that, I think.  This table doesn't get modified v=
ery=20
often, and I can afford to table-level lock it during modification.

However, I can't think of how I could implement a BEFORE ... FOR EACH=20
STATEMENT trigger that would check for duplicates in the final result.  I c=
an=20
only deal with one row at a time using the NEW record.

Suggestions?


--=20
-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
                                        Josh Berkus
   Complete information technology 	josh@agliodbs.com
    and data management solutions 	(415) 565-7293
   for law firms, small businesses 	 fax 621-2533
    and non-profit organizations. 	San Francisco