Re: set-level update fails with unique constraint violation
От | Scott Marlowe |
---|---|
Тема | Re: set-level update fails with unique constraint violation |
Дата | |
Msg-id | dcc563d11001021023p2cdd0ba2kdbfbb74999a3e8b4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: set-level update fails with unique constraint violation (Roman Neuhauser <neuhauser@sigpipe.cz>) |
Ответы |
Re: set-level update fails with unique constraint
violation
|
Список | pgsql-general |
On Sat, Jan 2, 2010 at 1:40 AM, Roman Neuhauser <neuhauser@sigpipe.cz> wrote: > # david@fetter.org / 2009-12-31 08:04:58 -0800: >> On Thu, Dec 31, 2009 at 10:52:20AM +0100, neuhauser+pgsql-general#postgresql.org@sigpipe.cz wrote: >> > Hello, >> > >> > this fails with "duplicate key value": >> > >> > CREATE TABLE x ( >> > i INT NOT NULL UNIQUE >> > ); >> > INSERT INTO x (i) VALUES (1), (2), (3); >> > UPDATE x SET i = i + 1; >> > >> > are there any plans to make this work? >> >> This will work in 8.5: >> >> CREATE TABLE x ( >> i int NOT NULL UNIQUE DEFERRABLE INITIALLY DEFERRED >> ); >> INSERT INTO x (i) VALUES (1), (2), (3); >> UPDATE x SET i = i + 1; > > thanks, this might be a bearable workaround in some cases > provided there's also SET CONSTRAINTS ... DEFERRED / IMMEDIATE. > what I really want is a mode that fires the constraint check > at the end of the statement. What advantage would there be to a constraint that fires right after to one that fires at the end of the transaction?
В списке pgsql-general по дате отправления: