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 http://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/
Show quoted text
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/
Show quoted text
From each according to his ability. To each according to his ability to litigate.