The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от opennews on 03-Фев-10, 14:18 
Компания 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

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +2 +/
Сообщение от skew email on 03-Фев-10, 14:18 
Ура! Мне очень понравилось работать с postgresql, и внутренние процедуры и функции писать на нём одно удовольствие, и к PHP к нему хорошая библиотека есть, и объектную модель можно построить. Сказка, а не SQL сервер.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 03-Фев-10, 15:56 
внутренние процедуры и функции...

По сравнению с некоторыми конечно получше, но по сравнению с некоторыми другими... Ни тебе модулей (пакетов), ни транзакций автономных, даже commit из функции неможет ;) Коечто у них в планах стоит, надеюсь со временем докрутят.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 03-Фев-10, 23:51 
> По сравнению с некоторыми конечно получше, но по сравнению с некоторыми другими... Ни тебе модулей (пакетов), ни транзакций автономных, даже commit из функции неможет ;) Коечто у них в планах стоит, надеюсь со временем докрутят.

А зачем это всё? Просто что бы «как в Oracle»? :) Мне лично не хватает только какого-либо решения для редактирования view при изменении объектов от которых оно зависит.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Diogene the Open Source programmer on 04-Фев-10, 00:48 
Да - для этого тоже. Продукт то для людей, я вот уже всё старьё 8.0.5 и некоторое 8.1.* перетащил не на 10g\11g а на Слоника ... почти dump\restore'ом! :) Сколько кило зелени сЪэкономил - прикинь сам.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 00:57 
Эка вы, не затем чтобы как в Oracle, а затем чтобы удобно, разве вьюхи нельзя пересоздать ? Пакеты и возможность простого сохранения это помоему базовые концепции программирования, наследование вон когда реализовали, а многоязычность ? куда ни нафиг приоритет, а возможности тупо закоммитить элементарный инсерт нет, пытался своих "проприетарщиков" свернуть, они когда узнали - ржали, было блин стыдно ;)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Ян Злобин email on 04-Фев-10, 03:12 
>возможности тупо закоммитить элементарный инсерт нет

А что мешает сделать инсерт отдельной функцией, вызываемой из первой?  Это и будет отдельный комит.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 10:52 
Какой функцией ? Я про обычный pgPL/SQL, в них нет коммита. Конечно может и можно чтото придумать написав какую то внешнюю не pgPL/SQL функцию коммита, но это ведь смешно, pgPL/SQL основной язык, представьте что вам гденить вместо обычного if придется использовать специальные функции из внешних модулей, при том что case будет доступен из коробки (rollback to savepoint в pgPL/SQL таки насколько я понимаю есть)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 13:15 
> pgPL/SQL основной язык

для postgres это не так, у него основной язык это SQL, а plpgsql это просто _один из многих_ процедурных языков.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 13:19 
>> pgPL/SQL основной язык
>
>для postgres это не так, у него основной язык это SQL, а
>plpgsql это просто _один из многих_ процедурных языков.

в догонку, в 8.5 (тобишь 9.0) собирались делать не именованные блоки на pl языках в теле запроса, вот когда сделают - тогда да, будет выглядеть странно, в теле запроса в блоке на pl нельзя будет делать commit; а пока я лично не вижу ничего плохого или странного что внутри процедур нельзя делать commit.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 13:25 
Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной процедурный язык, теперь даже установленный и используемый по умолчанию. Да и уж если на то пошло то из SQL'ных функций commit тоже нельзя ;)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 13:35 
>Ну мы ж про полноценное процедурное программирование, plpgsql какраз и есть основной
>процедурный язык, теперь даже установленный и используемый по умолчанию. Да и
>уж если на то пошло то из SQL'ных функций commit тоже
>нельзя ;)

процедурные языки сейчас нельзя использовать напрямую в теле запроса не создавая процедур, поэтому лично для меня отсутствие в них commit не выглядит каким-либо ограничением :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 13:43 
> процедурные языки сейчас нельзя использовать напрямую в теле запроса

ну так правильно, они для этого и концептуально не предназначены, их назначение выполнять запросы и обрабатывать/совмещать результаты, т.е. получать готовый сложный результат которого чистым SQL добиться невозможно, SQL внутри процедурного расширения но не наоборот. В этом плане от SQL функций коммита какраз требовать и не стоит, а вот в процедурных языках это основа их идеи.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 13:35 
в догонку
> не вижу ничего плохого или странного что внутри процедур нельзя делать commit

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 13:52 
>ну блин незнаю, это просто вы наверное привыкли, а вот и я
>лично, и вот народ вокруг сидит, считаем что это косяк. Сами
>подумайте написал я допустим процедуру по некой инициализации базы, чтото там
>сохранил, ессно надо чтобы другие транзакции эти изменения увидели, значит вместо
>просто вызова процедуры мне надо давать две команды, вызов процедуры а
>потом еще дополнительно коммит, ну это еще ладно мелочи

а Вы просто begin не делайте, тогда транзакция начнётся автоматически при входе в процедуру и автоматически закомтится при выходе или автоматически rollback при выходе если ошибка.

>дальше что я эту инициализацию встраиваю в другую процедуру, тут я
>уже коммит дополнительно дать не смогу, а в особенности интересно получается
>если в зависимости от некоторых условий этот коммит то надо давать
>то нет, т.е. управлять им программно.

тут можно обойтись rollback to savepoint по условию, если commit вызванной процедуры инициализации не нужен можно вернуться к savepoint которая была до вызова инициализации.

кажется понял, у Вас видимо долгоживущие сессии/транзакции, там наверное да, иногда нужно более хитро управлять commit'ом.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 14:10 
От ! приятно черт побери говорить с человеком который хочет тебя понять и говорит о конкретных вещах ;) Именно так, у меня транзакции по несколько минут могут жить, сотни вложенных хранимых процедур, вся логика в базе, настоящая так сказать промышленная СУБД ;) то что постгресом так упорно заявляется но на самом деле пока еще оно не совсем так, нехватает сущих "мелочей" типа техже пакетов, автономных транзакций и коммитов в первую очередь, оконные функции уже слава богу прикрутили. Конечно в принципе существует способ организации без commit, засчет savepoint, но он логически более сложен, замороченно получается, а для не то что больших, даже средних проектов это смерть.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 14:08 
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
$$;

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 14:41 
Насколько я понимаю в данном случае begin можно рассматривать как неявную установку savepoint, тогда при исключении идет выход из вложенного блока к этой savepoint. Это все хорошо, можно рулить что в результате сохраниться а что нет, после того как в конце произойдет коммит, но он мне не в конце нужен а в середине, чтобы остальные транзакции увидели изменения, и чтобы уж совсем бешенно длинных транзакций не разводить, логика мелких целостных шажков так сказать. Вот например делал недавно репликацию, там по приходу пакета в начале есть 4 логически целостных этапа предобработки, каждый может занимать по несколько минут, считаю логичным делать коммит после каждого из них, получается экономнее т.к. нет бешено длинных транзакций, да и по логике оно должно быть так ибо параллельно работающие процессы должны как можно раньше видеть результат первого этапа предобработки, ну и естественно это все в результате заворачивается в одну хранимую процедуру, набрал один раз call replicate() и вуаля ;)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от thirteensmay on 04-Фев-10, 14:47 
я уж не говорю о том что при наличии нормального человеческого commit вышеприведенный кусок сводится до элементарного:

insert into t values (99);
if p then commit; end if;
insert into t values (11);

ну блин ну есть жеш разница, а ? ;)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Ян Злобин email on 04-Фев-10, 03:09 
> Мне лично не хватает только какого-либо решения для редактирования view при изменении объектов от которых оно зависит.

Есть это давно.  Правило + Триггер.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от Аноним (??) on 04-Фев-10, 13:09 
>> Мне лично не хватает только какого-либо решения для редактирования 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;

и всё, приплыли, а если вьюх не две а десять ? а если колонка не добавляется а удаляется ? пока с этим сложно, нужно пересоздавать всё дерево зависимых вьюх и какого-то нормального решения не видно...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +2 +/
Сообщение от Vitaly_loki (ok) on 03-Фев-10, 15:10 
PostgreSQL - лучшая СУБД
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Несколько новых утилит для PostgreSQL. Вместо PostgreSQL 8.5..."  +/
Сообщение от letsmac on 04-Фев-10, 10:07 
9.0 эт хорошо. Ждём патчей от 1с, будем тестить.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру