Re: BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the same - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the same
Date
Msg-id 19863.1281107016@sss.pgh.pa.us
Whole thread Raw
In response to BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the same  ("Frank Heikens" <f.heikens@anva.nl>)
Responses Re: BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the same  (Frank Heikens <f.heikens@anva.nl>)
List pgsql-bugs
Frank Heikens <f.heikens@anva.nl> writes:
> The wikipage says
>> a deferrable constraint CAN be checked at the end of a
>> transaction. You still have to ask PostgreSQL to defer it.
> http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.0#DEFERRABLE_UNIQUE_CONSTRAINTS

> I don't have to ask PostgreSQL to defer, it works in the second test
as well in the third test without any changes. I guess the example in
the wiki isn't correct, right?

No, not even a little bit :-(.  I hadn't seen that text; it needs to be
corrected.  Will hack on it in a moment.

> A single UPDATE touching all records will check the uniqueness after the complete update, not right after each update
ofa row as it does on non-deferrable constraints. 

Right.
non-deferrable -> uniqueness is enforced after each row change
DEFERRABLE IMMEDIATE -> uniqueness is enforced at end of statement
DEFERRABLE DEFERRED -> uniqueness is enforced at end of transaction

> Maybe someone could make this clear in the manual and wiki?

AFAIK the manual is OK; do you see a place where it gets this wrong?

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Marcelo Mas"
Date:
Subject: BUG #5607: memmory leak in ecpg
Next
From: Tom Lane
Date:
Subject: Re: BUG #5606: DEFERRABLE and DEFERRABLE INITIALLY DEFERRED are the same