Change request ...

Even though many of the list members of pgsql-general(at)postgresql(dot)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.