Внезапно: транзакции в Postgresql

[metaclass]

Вот всю жизнь делаешь что-то, думаешь, что это очевидно, а потом берешь другую СУБД и оказывается, что там все сделано по другому.
Вот, например Postgresql vs Firebird:
1) В первом запросы отсылаются на сервер плейнтекстом, даже отпрепаренные с переменными. Во втором - сначала prepare, потом вызов полученного хендла с массивом параметров(бинарным) сколько надо раз. Впрочем, это может быть и особенность либы для доступа к Postgresql.
2) В первом транзакция одна на коннект, во втором - несколько на коннект.
3) В первом единственная ошибка в запросе в транзакции автоматом делает эту транзакцию невалидной целиком, и не дает ничего сделать до rollback. Во втором - транзакцию можно завершить, можно откатить, можно обработать ошибку и продолжить работать дальше. Не выполнится ровно один запрос. Чтобы имитировать такое в postgresql - нужно делать SAVEPOINT перед каждой query и откатываться на нее при ошибке.

Ну еще можно вспомнить про дотнет-драйвера обоих - в первом запрос-внутри-запроса выполнить невозможно, во втором свободно. Т.е. в postgresql "вычитать все шапки накладных, на каждую шапку вычитывая строки" - делается исключительно через жопие, методом "фетчим весь результат первого запроса, закрываем, затем выполняем второй сколько нужно раз".

Comments

[gds.livejournal.com]

1 -- в постгресе реально конченые prepared-операторы, в плохом смысле слова. но prepare там есть, и типа-хендлы тоже есть. но даже лучше бы не было, чтобы общность не нарушать.

2 -- последовательно -- можно. Параллельно -- мало смысла с точки зрения практики -- негламурненько, но не мешает особо.

3 -- уёбищно, факт.

Про дотнет-драйвера -- а что, до сих пор работаете с БД не через итераты и аппликативные функторы?

[w00dy.livejournal.com]

насчёт обработки ошибок - там жеж есть аналог try/catch

[jakobz.livejournal.com]

А вообще firebird - ок база? Как там перформанс и все такое? Просто ее как-то не особо юзают, при этом у нее вроде отличный набор фичей, и вообще она няшная. Почему так?

[stdray.livejournal.com]

А вы без всяких ОРМ справляетесь?

[filonenko-mikhail.blogspot.com (from livejournal.com)]

Судя по api libpq отсыл подготовленных данных имеет две версии текстовую и бинарную. Использование текстовой версии является предпочтительным, так как для нее гарантируется совместимость с другими версиями. Наверно это также стратегическое решение для упрощения написания драйверов на хост-языках без внешних зависимостей.

Возможно некоторые из ваших желаний могут быть реализованы на plpgsql. Функции на данном языке могу возвращать множество столбцов и строк. В 9-ой версии появились анонимные процедуры, возвращающие void (как в оракле). http://www.postgresql.org/docs/9.0/static/sql-do.html

Есть exceptions, которые можно использовать в plpgsql. http://www.postgresql.org/docs/9.1/interactive/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

А кроссплатформенность - это да, миф.

[sorhed.livejournal.com]

Учитывая количество червей в голове у Firebird (хотя мне нравилось ещё когда оно было Interbase), я даже как-то не представляю с чем собственно жить.

Пункты 1/2/3 везде так, или только под дотнетом?

[tzirechnoy.livejournal.com]

1) Да, особенность либы. И по-моему, в ODBC это где-то настраивалось (типа крыжыков версия такая-то).
2) Да, TCP делает это лучшэ.

В первом запрос-внутри-запроса делается ровно как во всём остальном SQL:

делаешь JOIN (лучшэ OUTER, можно SUB-SELECT), order by ШАПКА, и складываешь всё до изменения этой шапки в её строки.