Re: [HACKERS] Re: [QUESTIONS] Business cases

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: igor(at)nitek(dot)ru, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [QUESTIONS] Business cases
Date: 1998-01-21 18:38:07
Message-ID: Pine.NEB.3.95.980121133649.14635k-100000@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 21 Jan 1998, Bruce Momjian wrote:

> >
> >
> > Moved to pgsql-hackers(at)postgresql(dot)org, where it should have been moved
> > *ages* ago
> >
> > Connected to:
> > Oracle7 Server Release 7.3.3.0.0 - Production Release
> > With the distributed, replication and parallel query options
> > PL/SQL Release 2.3.3.0.0 - Production
> >
> > SQL> create table one ( a integer primary key not null );
> >
> > Table created.
> >
> > SQL> insert into one values (2);
> >
> > 1 row created.
> >
> > SQL> insert into one values (3);
> >
> > 1 row created.
> >
> > SQL> insert into one values (1);
> >
> > 1 row created.
> >
> > SQL> select * from one;
> >
> > A
> > ----------
> > 2
> > 3
> > 1
> >
> > SQL> update one set a=a+1;
> >
> > 3 rows updated.
> >
> > SQL> select * from one;
> >
> > A
> > ----------
> > 3
> > 4
> > 2
> >
>
> Man, how do you implement that behavior? No wonder MySQL fails on it
> too.

I don't know...the one suggestion that was made seemed to make
about the most sense...

If update is atomic, then it should allow you to change all the
resultant fields and then try to commit it. After all the fields are
changed, then it becomes 3,4,2 instead of 2,3,1, and, therefore, is all
unique...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ocie 1998-01-21 20:15:13 Re: [HACKERS] Re: [QUESTIONS] Business cases
Previous Message Bruce Momjian 1998-01-21 18:35:38 Re: [HACKERS] Re: [QUESTIONS] Business cases