> Your example:
>
> > Then again, Uniques might be useful deferred as well. For example,
> > one cannot do this:
> >
> > CREATE TABLE mytable
> > (
> > INTCOL INTEGER NOT NULL PRIMARY KEY
> > )
> > COMMIT;
> > INSERT INTO mytable VALUES (1);
> > INSERT INTO mytable VALUES (2);
> > INSERT INTO mytable VALUES (3);
> > COMMIT;
> >
> > UPDATE mytable SET intcol = intcol + 1;
> >
> > While the constraint itself - after all rows have been updated - is
> > perfectly valid.
>
> >From a theoretical point of view, this is a very sad and
> unfortunate failure to conform to the SQL standard. It's
> so a blatant violation of atomicity. It can't be that
> important in practice, or it would have been fixed
> already -- I hope.

It's a very simple example, of course. Nevertheless, other
examples that actually do use this are possible.

> "Believe it or not, there DBMSs alive today which will fail
> when they encounter this example's UPDATE statement."
> Peter Gulutzan, 1999

So you're saying that exactly this example is mentioned in
the SQL standard? Funny :-)

> Of course, now working for MySQL, poor Peter Gulutzan
> will have been confronted with even more unbelievable
> deviations from the standard.

btw, MySQL/InnoDB fails on this as well.

MS SQL Server does allow this.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com