Re: BUG #10429: the same update return different result

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Nieder <claudio(dot)nieder(dot)lists(at)inodes(dot)ch>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10429: the same update return different result
Date: 2014-05-23 19:34:05
Message-ID: 6125.1400873645@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Claudio Nieder <claudio(dot)nieder(dot)lists(at)inodes(dot)ch> writes:
>>> postgres=# update t1 set c1 = c1 +1;
>> This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command.
>>
> My understanding would have been, that "update t1 set c1=c1+1;" is ONE command, so even in the NOT DEFERRABLE case the check would occur only after both values were changed and as such not find any violation of the constraint.

The important detail is a bit further down the page, in the
"Compatibility" section:

Non-deferred Uniqueness Constraints

When a UNIQUE or PRIMARY KEY constraint is not deferrable, PostgreSQL
checks for uniqueness immediately whenever a row is inserted or
modified. The SQL standard says that uniqueness should be enforced only at
the end of the statement; this makes a difference when, for example, a
single command updates multiple key values. To obtain standard-compliant
behavior, declare the constraint as DEFERRABLE but not deferred (i.e.,
INITIALLY IMMEDIATE). Be aware that this can be significantly slower than
immediate uniqueness checking.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Ariel Bello 2014-05-24 15:16:50 Postgres 9.3 command line displaying language
Previous Message Claudio Nieder 2014-05-23 19:29:03 Re: BUG #10429: the same update return different result