> Naz Gassiep <naz@xxxxxxxx> writes: > > I would like more information on this deficiency and what causes it so I > > know when to anticipate it. > > The uniqueness constraint is checked on a row-by-row basis, so if you > update one row to hold the same value as another row holds, you get an > error immediately. It doesn't matter that if the query had been allowed > to finish, it would have updated that other row to some non-conflicting > value. (You might be able to work around this if you could control the > order in which rows are updated, but you can't.) > > This is not what the SQL spec says should happen, but so far no one has > proposed a reimplementation that doesn't give up unreasonable amounts > of performance. It's on the TODO list ... Is this related to the current limitations of "SET CONSTRAINTS"? http://www.postgresql.org/docs/8.1/interactive/sql-set-constraints.html Regards, Richard Broersma Jr.
