Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group