Обсуждение: Change request ...
Even though many of the list members of pgsql-general@postgresql.org suggest that the following is an expected behaviour, my experience in other databases doesn’t permit me accept it as such. I am putting this for the kind consideration of this list
Description : I have two tables with the same data , While I issue an update command to increment the value of a unique field by 1, the statement fails in one table and will succeed in the other table. Following is the script to reproduce the behaviour.
CREATE TABLE master1 ( m1 INT primary key , m2 INT unique ) ;
INSERT INTO master1 VALUES ( 1, 1 ) ;
INSERT INTO master1 VALUES ( 2, 2) ;
UPDATE master1 SET m2 = m2 + 1;
ERROR: duplicate key violates unique constraint "master1_m2_key"
SQL state: 23505
CREATE TABLE master2 ( m1 INT primary key , m2 INT unique ) ;
INSERT INTO master2 VALUES ( 2, 2 ) ;
INSERT INTO master2 VALUES ( 1, 1) ;
UPDATE master2 SET m2 = m2 + 1;
Am I right in requesting to this forum to make this update a success in either case.
Anoo S
Visit our Website at www.rmesi.co.in
This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. Internet communications are not secure; therefore, RMESI does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of RMESI. If this email has come to you in error, please delete it, along with any attachments. Please note that RMESI may intercept incoming and outgoing email communications.
Freedom of Information Act 2000
This email and any attachments may contain confidential information belonging to RMESI. Where the email and any attachments do contain information of a confidential nature, including without limitation information relating to trade secrets, special terms or prices these shall be deemed for the purpose of the Freedom of Information Act 2000 as information provided in confidence by RMESI and the disclosure of which would be prejudicial to RMESI's commercial interests.
This email has been scanned for viruses by Trend ScanMail.
Anoo Sivadasan Pillai wrote: > Even though many of the list members of pgsql-general@postgresql.org > suggest that the following is an expected behaviour, my experience in > other databases doesn't permit me accept it as such. I am putting this > for the kind consideration of this list I think it's more of a "known limitation" than anything else. > Description : I have two tables with the same data , While I issue an > update command to increment the value of a unique field by 1, the > statement fails in one table and will succeed in the other table. > Following is the script to reproduce the behaviour. AFAIK (and I'm not a developer) the problem is in two parts: 1. The only way to enforce UNIQUE at the moment is via a unique index. 2. A unique index enforces its requirements immediately. The reasons why it's not been addressed yet are: 1. Most unique constraints are on keys which aren't updated, so many people never have this problem. 2. It's quite a bit of work to solve. 3. There is a work-around (x=-x; x=-x + 1) It's already on the TODO: http://www.postgresql.org/docs/faqs.TODO.html Search for "Allow DEFERRABLE and end-of-statement UNIQUE constraints" If you can program in "C" or can fund someone who can, I'm sure people would like to see it fixed for version 8.4. Don't underestimate the work involved though. HTH -- Richard Huxton Archonet Ltd
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote: > Description : I have two tables with the same data , While I issue an > update command to increment the value of a unique field by 1, the > statement fails in one table and will succeed in the other table. > Following is the script to reproduce the behaviour. Correct. Unique constraints are not deferrable. I'm sure there are people who would like it fixed, but there is currently not even a proposal on how to do it. It's a hard problem, for which there are well-known work-arounds. In practice this problem don't come up too often. It's been on the TODO list for at least 5 years... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote: > On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote: >> Description : I have two tables with the same data , While I issue an >> update command to increment the value of a unique field by 1, the >> statement fails in one table and will succeed in the other table. >> Following is the script to reproduce the behaviour. > > Correct. Unique constraints are not deferrable. I'm sure there are > people who would like it fixed, but there is currently not even a > proposal on how to do it. It's a hard problem, for which there are > well-known work-arounds. In practice this problem don't come up too > often. > > It's been on the TODO list for at least 5 years... Wow, I was not aware of this limitation. MySQL hacks around this issue by allowing an ORDER BY in UPDATE (and DELETE) statements. regards, Lukas
On Thu, Sep 27, 2007 at 12:15:24PM +0200, Lukas Kahwe Smith wrote: > >It's been on the TODO list for at least 5 years... > > Wow, I was not aware of this limitation. MySQL hacks around this issue > by allowing an ORDER BY in UPDATE (and DELETE) statements. There is a similar workaround for postgres too, but it's a hack, it won't work in the general case. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.