softwarer1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него.

softwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.
О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде, а если не нужна --- не буду использовать. А в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)

Dimitry Sibiryakovsoftwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.
Ну так PG, видимо, не претендует...

С чего это наличие или отсутствие произвольных ограничений вдруг стало определять "нормальность" СУБД?

Alexander RyndinМне одному кажется, что вы какой-то бред несете?
Откуда я знаю, сколько вас здесь, "считающих"? ;)

Alexander Ryndin1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко.
А статистика, подтверждающая "в редких приложениях", у Вас есть? Или это информация агенства ОБС? ;) И как связаны "меняют разные данные" и DEADLOCK-и? Пускай 100500 клиентов конкурируют за одни и те же строки, но если они обрабатывают их в одном порядке, DEADLOCK-ов (без слишком крупных блокировок и т.п.) не будет вообще.

Alexander Ryndin Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)

Обычно да.

Alexander Ryndin2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться.

Безусловно, какой будет exception, заранее неизвестно. Но вот deadlock-и и update conflict-ы --- это нормальные ситуации в работе СУБД, и любому Database Developer должно быть известно, как их полагается обрабатывать.

Alexander RyndinНа каждый случай условных веток не напасешься.

Можно и напастись, т.к. обычно ошибки как-то разделяются на группы по severity и т.п.

Alexander RyndinНо всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля.

Да Вы что? А если пользователя просто нет ? Кому Вы будете это сообщение показывать?

Alexander Ryndin Какие к черту SAVEPOINT?
Те самые, которые есть в стандарте и во всех "нормальных СУБД"? Вот они все дураки-то, правда? ;)

Dimitry SibiryakovPgSQLAnonymousС чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?
С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

softwarerAlexander RyndinМне одному кажется, что вы какой-то бред несете?
Да не то чтобы бред. Слова уважаемого коллеги напоминают мне поведение юного головастого студента с большим самомнением, который нахватался вершков теории и при нуле практики начал придумывать улучшения и прочие единственно правильные подходы.
А мне Ваши, может, тоже чего-то напоминают. А аргументы-то есть у Вас?

softwarerPgSQLAnonymousпропущено...
Может откатиться до него
На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?
Естественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.

softwarerPgSQLAnonymousО каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,
Вот именно о таких обезьянках.
Нда. То есть возможность наличие выбора и возможность тривиально реализовать implict savepoint --- это недостаток, а отсутвие выбора --- это преимущество? Интересная у Вас логика.

softwarerЗа преимущество я выдаю удобную и правильную работу. А мучающиеся с грязным чтением, мумпсом и прочим каменным веком имеют полное право гордиться тем, что у них зато есть выбор.
Как здесь появились "грязное чтение, мумпсом и прочий каменным век"?
Ни с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...

Dimitry SibiryakovPgSQLAnonymousмне это поведение почему-то совсем не кажется "нормальным"
Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?

Я говорю, что мне это поведение кажется ненормальным, потому что я привык к другому. ;) Если его учитывать, то ничего плохого тут нет, я приказал --- он закоммитил, формально косяк здесь только мой. Но без implicit savepoints я могу выполнить это всё одним запросом/пакетом и знать, что данные не потеряются, а здесь нет, и это мне кажется ненормальным. ;(

pkarklinPgSQLAnonymousпропущено...

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

Я дико извиняюсь, что встреваю, но, в нормальной СУБД:




А в другой нормальной СУБД:


И что? ;)