Здравствуйте, Аноним, Вы писали:

А>>>оракл в точности соответствует ANSI (там нет требований упорядовачивать по коммиту), иначе бы их не пустили на tpc.org
M>>На что спорим?
А>на статью по эскалации
Ну тогда уже давно проспорил...
Поскольку в стандарте есть требование упорядоченности.

А>давай в это оригинальное решение добавим мелкими буквами не оригинальное оракловое
Это как раз оракловское решение "оригинальное". Еще раз перечитай внимательно, что я написал.
1. Требованиям ANSI SQL 99 оракловский "Serializable" не удовлетворяет.
2. Требованиям SQL 92 оракловский "Serializable" удовлетворяет лишь формально, благодаря расплывчатости формулировок в старой версии стандарта.
3. Посколько в требованиях tpc упомянута лишь необходимость RR, то ясен хвост, что оракловского "serializable" здесь хватает с избытком.
4. Оракл может сколько угодно играть терминами, как впрочем и любой другой производитель СУБД, но существует еще и формальная теория и стандарт. И если стандарт не дает четкого определения оракловского "Serializable" (зато дает определение Serializable, которому Оракл не удовлетворяет), то в формальной теории, то, что оракл называет "serializable" — называется Snapshot.

Собственно все вышесказанное вполне подтверждается приведенной тобой цитатой.

Но это все борьба за точность формулировок и не более того.
Главная же засада заключается в том, что если я в любой другой СУБД укажу SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, то я на 100% могу быть уверен, что проблем не будет. В то время как в Оракле я на это рассчитывать не могу.