X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id A8682D1B1E0 for ; Mon, 21 Jun 2004 07:15:12 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 27987-03 for ; Mon, 21 Jun 2004 10:15:09 +0000 (GMT) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by svr1.postgresql.org (Postfix) with ESMTP id B343ED1B1BC for ; Mon, 21 Jun 2004 07:15:05 -0300 (ADT) Received: from mwynhau.demon.co.uk ([193.237.186.96] helo=mainbox.archonet.com) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1BcLpS-0006q3-0V; Mon, 21 Jun 2004 11:15:06 +0100 Received: from [192.168.1.17] (client17.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id 8E2641699A; Mon, 21 Jun 2004 11:15:00 +0100 (BST) Message-ID: <40D6B523.9040109@archonet.com> Date: Mon, 21 Jun 2004 11:14:59 +0100 From: Richard Huxton User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luis Neves Cc: pgsql-sql@postgresql.org Subject: Re: Strange behaviour updating primary key column. References: <200406210729.07185.lneves@netcabo.pt> In-Reply-To: <200406210729.07185.lneves@netcabo.pt> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200406/191 X-Sequence-Number: 18136 Luis Neves wrote: > In the above table why does the query: > > UPDATE "story" > SET id = (id + 1500); > > fails with: > "ERROR: duplicate key violates unique constraint 'story_pkey'" > > (I have 6000 records in the table with "id" spanning from 1 to 6000) > > I find this behaviour strange, SQL is a set based language, but > PostgreSQL is acting like is changing the values in sequence. Quite right - it shouldn't happen. The issue is that the unique check isn't deferred, but is made whenever a value changes. So 1=>1501 of course gives the error. The work-around usually given is to do two updates: UPDATE story SET id = -id; UPDATE story SET id = -id + 1500; The real solution would be to check unique constraints at the end of statement, but I assume this is a tricky change or it would have been done by now. -- Richard Huxton Archonet Ltd