Re: On duplicate ignore
От
Scott Marlowe
Тема
Re: On duplicate ignore
Дата
Msg-id
CAOR=d=3Z=+gFSGQ+g_KsithQCGxhkpxg2tvD3tAis+FrfC=_vQ@mail.gmail.com
Ответ на
Re: On duplicate ignore (Florian Weimer)
Список
Дерево обсуждения
On duplicate ignore "Gnanakumar" <gnanam@zoniac.com>
Re: On duplicate ignore Atul Goel <Atul.Goel@iggroup.com>
Re: On duplicate ignore "Gnanakumar" <gnanam@zoniac.com>
Re: On duplicate ignore Florian Weimer <fweimer@bfk.de>
Re: On duplicate ignore Lincoln Yeoh <lyeoh@pop.jaring.my>
Re: On duplicate ignore Scott Marlowe <scott.marlowe@gmail.com>
Re: On duplicate ignore Florian Weimer <fweimer@bfk.de>
Re: On duplicate ignore Scott Marlowe <scott.marlowe@gmail.com>
Re: On duplicate ignore Dmitriy Igrishin <dmitigr@gmail.com>
Re: On duplicate ignore Atul Goel <Atul.Goel@iggroup.com>
On Thu, Jan 19, 2012 at 7:54 AM, Florian Weimer wrote: > * Gnanakumar: > >>> Just create a unique index on EMAIL column and handle error if it comes >> >> Thanks for your suggestion. Of course, I do understand that this could be >> enforced/imposed at the database-level at any time. But I'm trying to find >> out whether this could be solved at the application layer itself. Any >> thoughts/ideas? > > If you use serializable transactions in PostgreSQL 9.1, you can > implement such constraints in the application without additional > locking. However, with concurrent writes and without an index, the rate > of detected serialization violations and resulting transactions aborts > will be high. No, you sadly can't. PostgreSQL doesn't yet support proper predicate locking to allow the application to be sure that the OP's original statement, and ones like it, don't have a race condition. A unique index is the only way to be sure.
В списке pgsql-general по дате отправления
