PostgreSQL Mangos
 

Официально ядро поддерживает PostgreSQL , но почему в репозитории проекта лежат дампы только под MySQL??? Единственный *.sql файл для постгре это postgre_compatibility_addon.sql в котором создаются хранимые процедуры для замены стандартного типа timestamp'a. Сам синтаксис дампов только под MySQL, то есть эти дампы абсолютно нерабочие для PostgreSQL . Есть ли люди которые этим занимаются? И вообще планируется ли поддержка на уровне дампов PostgreSQL?

В contrib/mysql_to_pgsql лежин конвертор sql заросов - не 100% панацея конечно.

Среди разрабочиков из mangos team нет на данный момент пользующихся PostgreSQL.

Соответственно, нет.

В общем-то поддержка PostgreSQL фактически ограничена совместимостью запросов в коде ядра.

да надо было обратится к офф сайту сначало =\ , после создания темы нашел ответ твой на getmangos.com http://getmangos.com/community/post/132064/#p132064 .

ну хорошо буду дошлифовыват ьсвоими силами...

То есть я правильно понял, что помимо траблы решаемой запросами из postgre_compatibility_addon.sql есть еще какие то проблемы с работоспособностью для PostgreSQL?

Если структура базы правильная, то ядро должно работать нормально.
Конечно не с той скоростью, как с mySQL - из-за нереализованности prepared statements для PostgreSQL.

Смысла в постгресе для мангоса нет.

спасибо за разЪяснение

Ну во-первых нет ничего такого в MySQL , чего не было бы в PostgreSQL(если же нет, то оно либо не нужно либо реализовано иными средствами, причем второе справедливо в 90% процентах случаев).
Во-вторых видимо вы давно не заглядывали в документацию по постгре:declare: потому что для 8 и 9 ветки prepared statements реализованы и еще неизвестно где быстрее работает данный механизм (пруфы на офф маны http://www.postgresql.org/docs/curre...l-prepare.html http://www.postgresql.org/docs/8.0/s...l-prepare.html)
В-третьих насчет быстроты.В профессиональных кругах не секрет, что промышленное качество кода постгре в разы лучше MySQL(не зря же MySQL крайне не рекомендуют для продакшена) плюс свои уникальные алгоритмы работы и оптимизации ее. Вообще есть вики страница на офф сайте постгре , где говорится об ключевых отличиях http://wiki.postgresql.org/wiki/Why_..._of_MySQL_2009 . Но холивар не буду разводить ибо ресурс не для этого да и нелюбитель я их.Что действительно в MySQL есть это таблицы с движком MyISAM которые очень быстрые для чтения, но жертвуя при этом отказоустойчивостью и блокировки для записи.
цитата с вики про движок MyISAM
Но опять же постгре легко подстраивается под конкретные нужды, нужны лишь прямые руки и умение читать офф документацию:pardon:

P.S> Вообщем то я уже решил самостоятельно осуществить миграцию на постгре, уже собрал небольшой тулкит для миграции дампов с MYSQL на PostgreSQL(самописные и сторонние perl скрипты + прога из /contrib/mysql_to_pgsql), перевел и протестировал на работоспособность следующие дампы :
characters.sql
create_mysql.sql
mangos.sql
mangos_spell_check.sql
realmd.sql
и около половины из updates

есть еще проблемы,но думаю я их решу

P.S.S кому интересно perl-скрипты для миграции выложил в открытую часть репозитория своей сборки сервера https://bitbucket.org/unStatiK/firewow-server/src

Вы, наверное, не правильно поняли. В мангосе реализованы Prepared Statements только для MySQL. Если напишете патч, реализующий их для PostgreSQL, он может быть рассмотрен и принят в офф репо.

Хорошо, наверно и этим тоже займусь, потому что я очень заинтерисован в работоспособности постгре для мангоса

Вообще-то сам делал prepared для MySQL и Postgres. До этого постгрес мне не особо нравился, но запихивая prepared MySQL в класс мне показалось что делали он эту часть в свободное от работы время. А потом нарвался на мускульный глюк с невозможностью выполнения другого запроса пока открыт первый. А вот в постгрес всё логично.
Вот к примеру во вложении логон сервер на постгрес. Класс именно постгрес в Common/PostgresClasses.pas. Для тех кто не понимает Дельфи - переименуйте begin в {, end в }, а дальше почти одинаково.