Hi,
Bruce Momjian:
> >
> > > 2. atomic_updates = no
> > That's a misnomer. They actually mean this:
> >
> > create table crash_q (a integer not null);
> > create unique index crf on crash_q(a);
> >
> > insert into crash_q values (2);
> > insert into crash_q values (3);
> > insert into crash_q values (1);
> > update crash_q set a=a+1;
>
> Poorly named, huh? How do you think it got such a name? This item was
> on the crashme tests before TRANSACTION was on there?
It probably got that name because nobody thought about people
associating atomicity with transactions.
Anyway, the issue isn't all that exotic. ms-sql, mimer, db2, solid and
sybase are listed as supporting this kind of update.
If you can think of an understandable five-word-or-so description for
it, I'll happily rename the test. I've been thinking about it for the
last ten minutes or so, but couldn't come up with one. :-/
A different question is whether the database bungles the update when the
first few row can be updated and THEN you run into a conflict.
PostgreSQL handles this case correctly, MySQL doesn't => I'll add a
test for it.
--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
The only way to be good at everything you do is to only do the things
you are good at.