PostgreSQL Mangos

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

[Vladimir]

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

Есть ли люди которые этим занимаются?

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

И вообще планируется ли поддержка на уровне дампов PostgreSQL?

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

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

Сообщение от Vladimir

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

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

Сообщение от Vladimir

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

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

Сообщение от Vladimir

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

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

[Vladimir]

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

[Mediv]

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

Сообщение от Vladimir

Если структура базы правильная, то ядро должно работать нормально.

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

Сообщение от Vladimir

Конечно не с той скоростью, как с mySQL - из-за нереализованности prepared statements для PostgreSQL.

Ну во-первых нет ничего такого в MySQL , чего не было бы в PostgreSQL(если же нет, то оно либо не нужно либо реализовано иными средствами, причем второе справедливо в 90% процентах случаев).
Во-вторых видимо вы давно не заглядывали в документацию по постгре потому что для 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

This engine has excellent read performance for straightforward queries, which combine to make it very fast in read-intensive applications like web applications involving simple SELECTs. However, it is commonly known that MyISAM is more vulnerable to data corruption than most serious database applications would tolerate, and after a crash it can take a long time to repair the tables, during which the server is down. Furthermore, it does not support foreign keys or transactions that would allow the database to have ACID properties. MyISAM also has issues dealing with concurrent reads and updates, since it only provides table level locking.

Но опять же постгре легко подстраивается под конкретные нужды, нужны лишь прямые руки и умение читать офф документацию

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

[zergtmn]

Сообщение от 0xFF

потому что для 8 и 9 ветки prepared statements реализованы

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

Сообщение от zergtmn

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

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

[user456]

Сообщение от Vladimir

Конечно не с той скоростью, как с mySQL - из-за нереализованности prepared statements для PostgreSQL.

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