Unique Key Violation 7.0 vs. 6.5.3
От | Brian Hirt |
---|---|
Тема | Unique Key Violation 7.0 vs. 6.5.3 |
Дата | |
Msg-id | 20000406193037.B3604@loopy.berkhirt.com обсуждение исходный текст |
Ответы |
Re: Unique Key Violation 7.0 vs. 6.5.3
Re: Unique Key Violation 7.0 vs. 6.5.3 Re: Unique Key Violation 7.0 vs. 6.5.3 |
Список | 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
В списке pgsql-hackers по дате отправления: