> Naz Gassiep <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
