Unique Key Violation 7.0 vs. 6.5.3

From: Brian Hirt <bhirt(at)mobygames(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Brian Hirt <bhirt(at)loopy(dot)berkhirt(dot)com>
Subject: Unique Key Violation 7.0 vs. 6.5.3
Date: 2000-04-07 00:30:37
Message-ID: 20000406193037.B3604@loopy.berkhirt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

In doing some more 7.0 testing, I ran across a difference in functionality
concerning unique indexes and errors that are reported when you try to
violate the index. I'm not sure if this change is intentional, so I'm
bringing it up here. In 6.5.3, if you try to update a row that violates
a unique index, the query fails and said error is reported to the
application. However, in 7.0 the query succeeds, but updates 0 rows. Hence,
no errors are reported back to the application. This is not normally
a problem because I typically check the constrait before updating.

in 7.0/beta3
basement=> update foobar set unique_colum = '2000-04-09' where foobar_id = 32;
UPDATE 0
basement=>

in 6.5.3
basement=> update foobar set unique_colum = '2000-04-09' where foobar_id = 32;
ERROR: Cannot insert a duplicate key into a unique index
basement=>

--brian

--
The world's most ambitious and comprehensive PC game database project.

http://www.mobygames.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-04-07 00:33:37 RE: [HACKERS] Doc updates
Previous Message Hiroshi Inoue 2000-04-06 23:38:41 RE: 7.0 like selectivity