https://www.opennet.me/openforum/vsluhforumID3/63519.html Компания End Point открыла под лицензией BSD исходные тексты трех полезных утилит для PostgreSQL:<br><br><br>- tail_n_mail (http://bucardo.org/wiki/Tail_n_mail) - утилита для мониторинга за лог файлами и отправки уведомления по email в случае обнаружения определенных нештатных событий;<br>- boxinfo (http://bucardo.org/wiki/Boxinfo) - вывод в наглядном виде полезной информации о сервере и статистики;<br>- split_postgres_dump (http://bucardo.org/wiki/Split_postgres_dump) - разбивает содержимое SQL-дампа на две части: структуру базы и данные.<br><br><br><br><br><br>Кроме того, на очередном собрании основных разработчиков PostgreSQL принято (http://archives.postgresql.org/pgsql-hackers/2010-01/msg02056.php) решение о смене нумерации будущего релиза. Вместо версии 8.5 из-за значительности изменений будет выпущен релиз PostgreSQL 9.0.<br><br>URL: <br>Новость: http://www.opennet.ru/opennews/art.shtml?num=25278<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#26 Thu, 04 Feb 2010 11:47:13 GMT я уж не говорю о том что при наличии нормального человеческого commit вышеприведенный кусок сводится до элементарного:<br><br>insert into t values (99);<br>if p then commit; end if;<br>insert into t values (11);<br><br>ну блин ну есть жеш разница, а ? ;)<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#25 Thu, 04 Feb 2010 11:41:03 GMT Насколько я понимаю в данном случае begin можно рассматривать как неявную установку savepoint, тогда при исключении идет выход из вложенного блока к этой savepoint. Это все хорошо, можно рулить что в результате сохраниться а что нет, после того как в конце произойдет коммит, но он мне не в конце нужен а в середине, чтобы остальные транзакции увидели изменения, и чтобы уж совсем бешенно длинных транзакций не разводить, логика мелких целостных шажков так сказать. Вот например делал недавно репликацию, там по приходу пакета в начале есть 4 логически целостных этапа предобработки, каждый может занимать по несколько минут, считаю логичным делать коммит после каждого из них, получается экономнее т.к. нет бешено длинных транзакций, да и по логике оно должно быть так ибо параллельно работающие процессы должны как можно раньше видеть результат первого этапа предобработки, ну и естественно это все в результате заворачивается в одну хранимую процедуру, набрал один раз call replicate() и вуаля ;)<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#24 Thu, 04 Feb 2010 11:10:06 GMT От ! приятно черт побери говорить с человеком который хочет тебя понять и говорит о конкретных вещах ;) Именно так, у меня транзакции по несколько минут могут жить, сотни вложенных хранимых процедур, вся логика в базе, настоящая так сказать промышленная СУБД ;) то что постгресом так упорно заявляется но на самом деле пока еще оно не совсем так, нехватает сущих "мелочей" типа техже пакетов, автономных транзакций и коммитов в первую очередь, оконные функции уже слава богу прикрутили. Конечно в принципе существует способ организации без commit, засчет savepoint, но он логически более сложен, замороченно получается, а для не то что больших, даже средних проектов это смерть.<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#23 Thu, 04 Feb 2010 11:08:05 GMT rollback to savepoint внутри pl то же нельзя, я имел ввиду типа такого:<br><br>create function foo(p boolean) returns void language plpgsql as<br>$$<br>begin<br> begin<br> insert into t values (99);<br> if p then<br> raise exception 'rollback to last begin';<br> end if;<br> exception<br> when others then<br> -- noop<br> end;<br> insert into t values (11);<br>end<br>$$;<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#22 Thu, 04 Feb 2010 10:52:23 GMT &gt;ну блин незнаю, это просто вы наверное привыкли, а вот и я <br>&gt;лично, и вот народ вокруг сидит, считаем что это косяк. Сами <br>&gt;подумайте написал я допустим процедуру по некой инициализации базы, чтото там <br>&gt;сохранил, ессно надо чтобы другие транзакции эти изменения увидели, значит вместо <br>&gt;просто вызова процедуры мне надо давать две команды, вызов процедуры а <br>&gt;потом еще дополнительно коммит, ну это еще ладно мелочи<br><br>а Вы просто begin не делайте, тогда транзакция начнётся автоматически при входе в процедуру и автоматически закомтится при выходе или автоматически rollback при выходе если ошибка.<br><br>&gt;дальше что я эту инициализацию встраиваю в другую процедуру, тут я <br>&gt;уже коммит дополнительно дать не смогу, а в особенности интересно получается <br>&gt;если в зависимости от некоторых условий этот коммит то надо давать <br>&gt;то нет, т.е. управлять им программно. <br><br>тут можно обойтись rollback to savepoint по условию, если commit вызванной процедуры инициализации не нужен можно вернуться к savepoint которая была до в https://www.opennet.me/openforum/vsluhforumID3/63519.html#21 Thu, 04 Feb 2010 10:43:44 GMT &gt; процедурные языки сейчас нельзя использовать напрямую в теле запроса<br><br>ну так правильно, они для этого и концептуально не предназначены, их назначение выполнять запросы и обрабатывать/совмещать результаты, т.е. получать готовый сложный результат которого чистым SQL добиться невозможно, SQL внутри процедурного расширения но не наоборот. В этом плане от SQL функций коммита какраз требовать и не стоит, а вот в процедурных языках это основа их идеи.<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#20 Thu, 04 Feb 2010 10:35:49 GMT в догонку<br>&gt; не вижу ничего плохого или странного что внутри процедур нельзя делать commit<br><br>ну блин незнаю, это просто вы наверное привыкли, а вот и я лично, и вот народ вокруг сидит, считаем что это косяк. Сами подумайте написал я допустим процедуру по некой инициализации базы, чтото там сохранил, ессно надо чтобы другие транзакции эти изменения увидели, значит вместо просто вызова процедуры мне надо давать две команды, вызов процедуры а потом еще дополнительно коммит, ну это еще ладно мелочи, но представьте дальше что я эту инициализацию встраиваю в другую процедуру, тут я уже коммит дополнительно дать не смогу, а в особенности интересно получается если в зависимости от некоторых условий этот коммит то надо давать то нет, т.е. управлять им программно.<br><br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#19 Thu, 04 Feb 2010 10:35:35 GMT &gt;Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной <br>&gt;процедурный язык, теперь даже установленный и используемый по умолчанию. Да и <br>&gt;уж если на то пошло то из SQL'ных функций commit тоже <br>&gt;нельзя ;) <br><br>процедурные языки сейчас нельзя использовать напрямую в теле запроса не создавая процедур, поэтому лично для меня отсутствие в них commit не выглядит каким-либо ограничением :)<br> https://www.opennet.me/openforum/vsluhforumID3/63519.html#18 Thu, 04 Feb 2010 10:25:34 GMT Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной процедурный язык, теперь даже установленный и используемый по умолчанию. Да и уж если на то пошло то из SQL'ных функций commit тоже нельзя ;)<br>