> > Incrementing comand counter is not enough - dirty reads are required
> > to handle concurrent PK updates.
>
> What's that with you and dirty reads? Every so often you tell
> me that something would require them - you really like to
> read dirty things - no? :-)
Dirty things o
> > > update a set a=a+1 where a>2;
> > > ERROR: Cannot insert a duplicate key into unique index a_pkey
> >
> > We use uniq index for UK/PK but shouldn't. Jan?
>
> What else can you use than an index? A "deferred until
> statement end" trigger checking for duplicates? Think it'
> > update a set a=a+1 where a>2;
> > ERROR: Cannot insert a duplicate key into unique index a_pkey
>
> This is a known problem with unique contraints, but it's not
> easy to fix it.
Yes, it requires dirty reads.
Vadim
---(end of broadcast)---
T
> Problem can be demonstrated by following example
>
> create table a (a numeric primary key);
> insert into a values (1);
> insert into a values (2);
> insert into a values (3);
> insert into a values (4);
> update a set a=a+1 where a>2;
> ERROR: Cannot insert a duplicate key into unique index