* Albe Laurenz: > That sounds like it should actually work.
If you have got an index, yes. It seems to me that it would make locking behavior dependent on your query plan, too. BTW, PostgreSQL could raise a different error when a unique constraint violation is detected which involves a row which is not visible at the current snapshot. At least in my limited experience, that would allow applications to recover more easily if small transactions fail (similar to what you have to do on deadlock). Right now (well, at least with 8.3, haven't checked 8.4 yet), it's not possible to tell a unique constraint violation caused by a phantom from an application bug. (We currently faking this by retrying a fixed number of times and bailing out if the error returned by PostgreSQL looks like a unique constraint violation.) -- Florian Weimer <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
