https://www.opennet.me/openforum/vsluhforumID3/81508.html Представлен (http://permalink.gmane.org/gmane.comp.db.postgresql.announce/1935) PGXN Client 1.0 (http://pgxnclient.projects.postgresql.org/), первый релиз клиентского приложения, предназначенного для автоматизации поиска, загрузки, сборки, установки и удаления дополнений для СУБД PostgreSQL, представленных в архиве PGXN (http://pgxn.org/) (PostgreSQL Extension Network). Например, для установки определённого дополнения на сервер достаточно выполнить "pgxn install дополнение", а для загрузки дополнения только для одной БД - "pgxn load -d БД дополнение".<br><br><br>В рамках проекта PGXN развивается напоминающий CPAN архив для распространения дополнений к СУБД PostgreSQL, включая реализацию инфраструктуры для загрузки и распространения дополнений, подготовку централизованного индекса и API для доступа к мета-данным, создание системы поиска дополнений и набора утилит для тестирования дополнений. В настоящий момент в архиве представлено 57 дополнений и 105 релизов. <br><br><br>Среди полезных дополнений:...<br><br>URL: http://permali https://www.opennet.me/openforum/vsluhforumID3/81508.html#23 Fri, 16 Dec 2011 12:44:25 GMT &gt; критикал приложения обычно в критикал бизнесе, в остальном все вольные художники. Нет <br>&gt; ничего плохого втом, что скажем, СУБД поработала на фряхе, а потом <br>&gt; переехала на центос или наоборот, поскольку таргет платформа вырвалась в илдеры <br>&gt; по ряду ключевых параметров (тут каждому своё). И вот выясняется, что <br>&gt; при перезде "отвалился" сервис, хотя в остальном ожидаемый профит получен.<br><br>Это косяк архитектора и project manager, что не проверили рабоче-способность софта на таргет платформе И не учли эту проблему при risk-management И перенесли продакшен не взирая на подобную возможность.<br><br>У нас все проще. Стоимость проекта намного больше лицензий на ОС и СУБД, потому не особо запариваясь покупается RHEL и Oracle. опять же есть тренированные шаманы (админы) и по RHEL и по Oracle (DBA). Так что перенос на что-то альтернативное типа PostgreSQL или FreeBSD конечно возможен, но только в том случае, если связка RHEL+Oracle по какой то причине не может обеспечить требуемый функционал.<br><br><br>PS цена PostgreSQL https://www.opennet.me/openforum/vsluhforumID3/81508.html#22 Tue, 29 Nov 2011 14:28:55 GMT &gt; В том что есть вот у меня системный манагер пакетов.<br><br>Так прям разработчики плагинов для постгреса/руби/перла/теха/похапе/etc и побежали упаковывать свои модули в десятки форматов пакетов и проталкивать их в штатные репы 100500 дистров, ага.<br><br>Гораздо проще, если у каждого проекта будет свой репозитарий со своим внутренним форматом, а у каждого заинтересованного дистра - скрипты-конверторы в свой родной формат пакетов.<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#21 Tue, 29 Nov 2011 11:27:54 GMT &gt; Надоели уже все эти самопальные подобия нормального пакетного менеджера. <br><br>Репозитарии с автоматизированной установкой, с точки зрения интеграции со штатным пакетным менеджером, гораздо проще и удобнее, чем раскиданные по сайтам разработчиков тарболы произвольной структурой с километровыми и откровенно наркоманскими INSTALL.<br><br>Вон в дебиане уже давно работают автоматические преобразователи пакетов CPAN и CTAN в deb.<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#20 Tue, 29 Nov 2011 03:12:11 GMT критикал приложения обычно в критикал бизнесе, в остальном все вольные художники. Нет ничего плохого втом, что скажем, СУБД поработала на фряхе, а потом переехала на центос или наоборот, поскольку таргет платформа вырвалась в илдеры по ряду ключевых параметров (тут каждому своё). И вот выясняется, что при перезде "отвалился" сервис, хотя в остальном ожидаемый профит получен. В идеальном вакууме, в идеальной сферической системе, очевидно должен быть протокол управления зависимостями програмных модулей от ядра до софта самого последнего уровня. Как только софт оторвался от бинарного компилера, всё, он "живёт" в своей среде, и ему наплевать, например, на то что на целевой платформе парсер XML (к примеру) не "той" версии. И вроде всё работает, да как то не так... Что уж говорить про критикал СУБД на критикал платформах.<br><br>высказался, извиняйте, что сильно отвлёк.<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#19 Mon, 28 Nov 2011 20:29:19 GMT Под critical приложения ставят СУБД и под нее подбирают наиболее подходящую ОС. Вряд ли это для вас секрет ;)<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#18 Mon, 28 Nov 2011 14:44:50 GMT &gt; Есть СУБД (как и любые большие приложения), которая по сути ОС-независимая, <br><br>Угу. Поэтому надо еще и операционку свою припереть. А то вдруг моя операционка неправильная. Ну пакетный менеджер же может быть неправильным. Значит и операционка целиком - тоже.<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#17 Mon, 28 Nov 2011 14:28:27 GMT &gt; В том что есть вот у меня системный манагер пакетов. <br><br>Вот ты и запили ОС-независимый плагин под свой ситемный манагер пакетов и протолкни в репо дистра ;) <br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#16 Mon, 28 Nov 2011 13:49:07 GMT Это проблемы Вашего дистрибутива и его майнтейнеров.<br><br>В Debian например есть почти автоматический скрипт делающий из модуля CPAN пакет, есть уже готовые такие пакеты поддерживаемые в рамках репозитория пакетов Debian. То же самое будет и с PGXN.<br> https://www.opennet.me/openforum/vsluhforumID3/81508.html#14 Mon, 28 Nov 2011 13:35:34 GMT &gt; А в чем проблемы-то?<br><br>В том что есть вот у меня системный манагер пакетов. Нет, надо еще в пяти местах свои самопальные припереть, как в винде.<br>