Здравствуйте!
Интересует вопрос, оно у кого-нибудь скомпилировалось? А то жалуется на
#include "unicode/uchar.h"
#include "unicode/ustring.h"
в файле contrib/mchar/mchar.h. Таковых заголовочных файлов нет в PostgreSQL, и 1Сными патчами такого не добавляется. Опции gcc насчёт пути include'ов гласят ../../src/include, т.е. основное дерево исходников PostgreSQL. судля по поиску на postgresql.org, таких файлов и не было никогда в PostgreSQL.

(0)
Я. Попробуй другой дистрибутив(не прикол)

(1)На самом деле компилил?

(1) Должно и под OpenSuSE работать :)

ты не можешь случайно сделать rpm -qf /usr/include/unicode/uchar.h ?

(1) не прикалывайся :)
нашёл причину проблемы - надо установить libicu-devel :)
Всем спасибо, очередная ошибка в моём ДНК найдена :)

(4)походу ты тут едиственный из линусятников реально пытающий юзать 1С под линем и этим бесплатным скулом...

(5) А что, остальные тока под виндой? Я уже под OpenSuSE запустил сервер
приложений под 1С-овской бинарной сборкой PostgreSQL 8.2.4, работает. Тока
неправильно это, надо делать нативный SuSEшный пакет с 1Совскими патчами.

(6)Да я хз что там делают остальные линусятники. Скорее всего, как обычно, пятки выворачивают.

Кстати, в тему:

PostgreSQL публикует свой первый настоящий тест на производительность

Группа OpenSource На мероприятии, посвящённому дню PostgreSQL - PostgreSQL Day
(aka PGDday), проходившему в Прато (Италия), Sun и PostgreSQL опубликовали
результаты первого теста на производительность, которые примечательны тем, что:
Это первые тесты промышленного уровня для PostgreSQL.
Больше нет "медленного слона". Тесты показали, что PostgreSQL не только
является быстрым или быстрее, чем MySQL, но и почти таким же быстрым, как
Oracle (так как аппаратные платформы разные, трудно сравнивать напрямую).
Niagara является хорошей платформой для приложений баз данных.
Говоря о масштабируемости, можно гордиться тем, что показывает PostgreSQL
сейчас. В планах, сделать так, чтобы PostgreSQL мог спокойно масштабироваться
на 128 или 256 ядрах.
Это не последние тесты такого уровня для PostgreSQL, для оптимизации PostgreSQL
пришлось пожертвовать некоторыми компонентами и, в скором будущем, планируется
повторить тесты с ещё более высокими результатами. По словам разработчиков, им
не достаточно просто быть "почти быстрым, как Oracle" - в планах, обогнать
Oracle, возможно начиная с PostgreSQL 8.3 и Niagara2.

Результаты тестов:
http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070606-00065.html
Подробности:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-real-benchmark-17470

Скопипасчено с linux.org.ru

И вылезла ещё одна ошибка при сборке - в идеале надо rpmbuild делать от рута, а
в скрипте сборки postgreSQL вызывается initdb, которая от рута работать не
может. Не собирается :) Будем копать :)

(5)
Человек не ищет легких путей...

(10) Чем я сильно отличаюсь от тех, кто ставит почти рабочие базы на 8.1.8?

хм.. а у меня SRPM нету... только RPM.

(12) 1Совский srpm лежит там же, где и патчи. OpenSuSEшный - в
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/

спасибо, поиграюсь.

Проще всего брать родные сорцы, накладывать на них 1ц патчи и собирать в таком виде, все работает под любым линухом.

(15) Ага, но некошерно. А компилить src.rpm от федоры в SuSE некошерно
вдвойне :)

(16) А чего некошерного в тарболлах или bz2? :)
Зато все просто. И одинаково на любой системе :)

+16 Просто существует некая философия использования софта под различными
дистрибутивами, и она гласит: не собирай из исходников сразу в корень, собирай
сначала пакет, а потом ставь его. Если не сделаешь этого - сразу нарушится
целостность, невозможно станет обновляться, трудно станет удалить именно эту
программу и т.д.

Хех, скомпилировал. Завтра буду пробовать :)

Вот появилась ещё одна "особенность". При загрузке базы из .dt-файла не
загружаются константы. Платформа 8.1.10, PostgreSQL 8.2.4. Вот интересует меня,
это чей косяк?