Обсуждение: Change request ...

Поиск
Список
Период
Сортировка

Change request ...

От
"Anoo Sivadasan Pillai"
Дата:

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.

Re: Change request ...

От
Richard Huxton
Дата:
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


Re: Change request ...

От
Martijn van Oosterhout
Дата:
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.

Re: Change request ...

От
Lukas Kahwe Smith
Дата:
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


Re: Change request ...

От
Martijn van Oosterhout
Дата:
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.