Внезапно: транзакции в 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

[metaclass.livejournal.com]

Да нету там ничего подходящего.
Задача тупо "выполнить запрос, если он свалился - выполнить другой, который не свалится". Без всякого серверного кода, тупо из клиента. Хрен там.

[plumqqz.livejournal.com]

"И в третий раз закинул он невод..."

$dbh->do(<<'EOL'
do $CODE$
begin
 select 1/0;
 raise notice 'Oops... 8-0';
 exception
  when division_by_zero then
    raise notice 'got exception';
  end;
$CODE$
EOL
);

[metaclass.livejournal.com]

А, оно умеет psql в запросах с клиента выполнять?

[plumqqz.livejournal.com]

psql - это консольный клиент такой. Не, его не умеет.
А вот plpgsql умеет. В общем должно и всякое остальное уметь, но я не пробовал. Да, и я не знаю, как во всяком основном с транзакциями.

[plumqqz.livejournal.com]

Тьфу. s/основном/остальном/;

[jakobz.livejournal.com]

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

[plumqqz.livejournal.com]

Попробуйте insert into tbl select * from tbl

[metaclass.livejournal.com]

Да, да, cursor stability вроде пока так и не пофиксили.

[metaclass.livejournal.com]

Перформанс чуть меньше среднего по больнице.
Фичей некоторых полезных нет - типа partitioning, репликации нормальной, итд итп. Из фич уровня языка разве что window functions не хватает, остальное весьма хорошо.
Со служебными средствами (человеческие логи, средства мониторинга, утилиты, текстовый бэкап) - печально, разработчики считают что это не нужно и занимаются больше внутренностями БД.
С документацией не очень хорошо. Комьюнити немного самоогороженное, нервничают когда про них пишут.

Очень удобна для мелких-средних проектов, с точки зрения программирования. Серверный код (императивное расширение sql) достаточно логично устроен, компонент доступа чуть более чем дохрена. Средств разработки под нее как бы не больше чем средств эксплуатации.

[j-sheridan.livejournal.com]

На "человеческие логи" несколько завис, ибо воображение шустро нарисовало рубленных человеков, сложенных в штабеля ))

[fraks-nsk.livejournal.com]

Текстовый бэкап нормально получается с помощью IBExpert. Постоянно это дело не юзаю но использовал при переходе с версии на версию, и даже был удивлен скоростью заливки данных из скрипта. Я ожидал что будет намного медленнее.
Однако если сырцы триггеров и процедур из базы удалены - то конечно в таком случае текстовый бэкап не проканает.

[theiced.livejournal.com]

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

[jakobz.livejournal.com]

рашкиноидами?

[theiced.livejournal.com]

да. чуть более чем все девелоперы - рашкиноиды.

[stdray.livejournal.com]

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

[metaclass.livejournal.com]

Обычно да.

[w00dy.livejournal.com]

Вменяемая кодогенерация? Чистый sql где-то пользуется в коде?

[metaclass.livejournal.com]

Раньше sql, счас кодогенерация.

[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 везде так, или только под дотнетом?

[metaclass.livejournal.com]

Везде.

[sorhed.livejournal.com]

Бяда, конечно.

[tzirechnoy.livejournal.com]

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

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

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