Компания End Point открыла под лицензией BSD исходные тексты трех полезных утилит для PostgreSQL:
- tail_n_mail (http://bucardo.org/wiki/Tail_n_mail) - утилита для мониторинга за лог файлами и отправки уведомления по email в случае обнаружения определенных нештатных событий;
- boxinfo (http://bucardo.org/wiki/Boxinfo) - вывод в наглядном виде полезной информации о сервере и статистики;
- split_postgres_dump (http://bucardo.org/wiki/Split_postgres_dump) - разбивает содержимое SQL-дампа на две части: структуру базы и данные.Кроме того, на очередном собрании основных разработчиков PostgreSQL принято (http://archives.postgresql.org/pgsql-hackers/2010-01/msg0205...) решение о смене нумерации будущего релиза. Вместо версии 8.5 из-за значительности изменений будет выпущен релиз PostgreSQL 9.0.
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=25278
Ура! Мне очень понравилось работать с postgresql, и внутренние процедуры и функции писать на нём одно удовольствие, и к PHP к нему хорошая библиотека есть, и объектную модель можно построить. Сказка, а не SQL сервер.
внутренние процедуры и функции...По сравнению с некоторыми конечно получше, но по сравнению с некоторыми другими... Ни тебе модулей (пакетов), ни транзакций автономных, даже commit из функции неможет ;) Коечто у них в планах стоит, надеюсь со временем докрутят.
> По сравнению с некоторыми конечно получше, но по сравнению с некоторыми другими... Ни тебе модулей (пакетов), ни транзакций автономных, даже commit из функции неможет ;) Коечто у них в планах стоит, надеюсь со временем докрутят.А зачем это всё? Просто что бы «как в Oracle»? :) Мне лично не хватает только какого-либо решения для редактирования view при изменении объектов от которых оно зависит.
Да - для этого тоже. Продукт то для людей, я вот уже всё старьё 8.0.5 и некоторое 8.1.* перетащил не на 10g\11g а на Слоника ... почти dump\restore'ом! :) Сколько кило зелени сЪэкономил - прикинь сам.
Эка вы, не затем чтобы как в Oracle, а затем чтобы удобно, разве вьюхи нельзя пересоздать ? Пакеты и возможность простого сохранения это помоему базовые концепции программирования, наследование вон когда реализовали, а многоязычность ? куда ни нафиг приоритет, а возможности тупо закоммитить элементарный инсерт нет, пытался своих "проприетарщиков" свернуть, они когда узнали - ржали, было блин стыдно ;)
>возможности тупо закоммитить элементарный инсерт нетА что мешает сделать инсерт отдельной функцией, вызываемой из первой? Это и будет отдельный комит.
Какой функцией ? Я про обычный pgPL/SQL, в них нет коммита. Конечно может и можно чтото придумать написав какую то внешнюю не pgPL/SQL функцию коммита, но это ведь смешно, pgPL/SQL основной язык, представьте что вам гденить вместо обычного if придется использовать специальные функции из внешних модулей, при том что case будет доступен из коробки (rollback to savepoint в pgPL/SQL таки насколько я понимаю есть)
> pgPL/SQL основной языкдля postgres это не так, у него основной язык это SQL, а plpgsql это просто _один из многих_ процедурных языков.
>> pgPL/SQL основной язык
>
>для postgres это не так, у него основной язык это SQL, а
>plpgsql это просто _один из многих_ процедурных языков.в догонку, в 8.5 (тобишь 9.0) собирались делать не именованные блоки на pl языках в теле запроса, вот когда сделают - тогда да, будет выглядеть странно, в теле запроса в блоке на pl нельзя будет делать commit; а пока я лично не вижу ничего плохого или странного что внутри процедур нельзя делать commit.
Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной процедурный язык, теперь даже установленный и используемый по умолчанию. Да и уж если на то пошло то из SQL'ных функций commit тоже нельзя ;)
>Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной
>процедурный язык, теперь даже установленный и используемый по умолчанию. Да и
>уж если на то пошло то из SQL'ных функций commit тоже
>нельзя ;)процедурные языки сейчас нельзя использовать напрямую в теле запроса не создавая процедур, поэтому лично для меня отсутствие в них commit не выглядит каким-либо ограничением :)
> процедурные языки сейчас нельзя использовать напрямую в теле запросану так правильно, они для этого и концептуально не предназначены, их назначение выполнять запросы и обрабатывать/совмещать результаты, т.е. получать готовый сложный результат которого чистым SQL добиться невозможно, SQL внутри процедурного расширения но не наоборот. В этом плане от SQL функций коммита какраз требовать и не стоит, а вот в процедурных языках это основа их идеи.
в догонку
> не вижу ничего плохого или странного что внутри процедур нельзя делать commitну блин незнаю, это просто вы наверное привыкли, а вот и я лично, и вот народ вокруг сидит, считаем что это косяк. Сами подумайте написал я допустим процедуру по некой инициализации базы, чтото там сохранил, ессно надо чтобы другие транзакции эти изменения увидели, значит вместо просто вызова процедуры мне надо давать две команды, вызов процедуры а потом еще дополнительно коммит, ну это еще ладно мелочи, но представьте дальше что я эту инициализацию встраиваю в другую процедуру, тут я уже коммит дополнительно дать не смогу, а в особенности интересно получается если в зависимости от некоторых условий этот коммит то надо давать то нет, т.е. управлять им программно.
>ну блин незнаю, это просто вы наверное привыкли, а вот и я
>лично, и вот народ вокруг сидит, считаем что это косяк. Сами
>подумайте написал я допустим процедуру по некой инициализации базы, чтото там
>сохранил, ессно надо чтобы другие транзакции эти изменения увидели, значит вместо
>просто вызова процедуры мне надо давать две команды, вызов процедуры а
>потом еще дополнительно коммит, ну это еще ладно мелочиа Вы просто begin не делайте, тогда транзакция начнётся автоматически при входе в процедуру и автоматически закомтится при выходе или автоматически rollback при выходе если ошибка.
>дальше что я эту инициализацию встраиваю в другую процедуру, тут я
>уже коммит дополнительно дать не смогу, а в особенности интересно получается
>если в зависимости от некоторых условий этот коммит то надо давать
>то нет, т.е. управлять им программно.тут можно обойтись rollback to savepoint по условию, если commit вызванной процедуры инициализации не нужен можно вернуться к savepoint которая была до вызова инициализации.
кажется понял, у Вас видимо долгоживущие сессии/транзакции, там наверное да, иногда нужно более хитро управлять commit'ом.
От ! приятно черт побери говорить с человеком который хочет тебя понять и говорит о конкретных вещах ;) Именно так, у меня транзакции по несколько минут могут жить, сотни вложенных хранимых процедур, вся логика в базе, настоящая так сказать промышленная СУБД ;) то что постгресом так упорно заявляется но на самом деле пока еще оно не совсем так, нехватает сущих "мелочей" типа техже пакетов, автономных транзакций и коммитов в первую очередь, оконные функции уже слава богу прикрутили. Конечно в принципе существует способ организации без commit, засчет savepoint, но он логически более сложен, замороченно получается, а для не то что больших, даже средних проектов это смерть.
rollback to savepoint внутри pl то же нельзя, я имел ввиду типа такого:create function foo(p boolean) returns void language plpgsql as
$$
begin
begin
insert into t values (99);
if p then
raise exception 'rollback to last begin';
end if;
exception
when others then
-- noop
end;
insert into t values (11);
end
$$;
Насколько я понимаю в данном случае begin можно рассматривать как неявную установку savepoint, тогда при исключении идет выход из вложенного блока к этой savepoint. Это все хорошо, можно рулить что в результате сохраниться а что нет, после того как в конце произойдет коммит, но он мне не в конце нужен а в середине, чтобы остальные транзакции увидели изменения, и чтобы уж совсем бешенно длинных транзакций не разводить, логика мелких целостных шажков так сказать. Вот например делал недавно репликацию, там по приходу пакета в начале есть 4 логически целостных этапа предобработки, каждый может занимать по несколько минут, считаю логичным делать коммит после каждого из них, получается экономнее т.к. нет бешено длинных транзакций, да и по логике оно должно быть так ибо параллельно работающие процессы должны как можно раньше видеть результат первого этапа предобработки, ну и естественно это все в результате заворачивается в одну хранимую процедуру, набрал один раз call replicate() и вуаля ;)
я уж не говорю о том что при наличии нормального человеческого commit вышеприведенный кусок сводится до элементарного:insert into t values (99);
if p then commit; end if;
insert into t values (11);ну блин ну есть жеш разница, а ? ;)
> Мне лично не хватает только какого-либо решения для редактирования view при изменении объектов от которых оно зависит.Есть это давно. Правило + Триггер.
>> Мне лично не хватает только какого-либо решения для редактирования view при изменении объектов от которых оно зависит.
>
>Есть это давно. Правило + Триггер.create table departments (dep_id serial, dep_name text);
create table users (id serial, name text, dep_id int, is_enabled boolean);
create view active_users as select * from users where is_enabled;
create view managers as select * from active_users join departments using (dep_id) where dep_name = 'managers';alter table users add email text;
и всё, приплыли, а если вьюх не две а десять ? а если колонка не добавляется а удаляется ? пока с этим сложно, нужно пересоздавать всё дерево зависимых вьюх и какого-то нормального решения не видно...
PostgreSQL - лучшая СУБД
9.0 эт хорошо. Ждём патчей от 1с, будем тестить.