Drupal + PostgreSQL: вторая попытка

Внезапно возникшее отвращение к MySQL (каменты тоже читать) заставило посмотреть на связку Drupal + PostgreSQL еще раз.

Если аккуратно, то все работает. Т.е. к core у меня и раньше претензий не было, а сломался я в модуле Backup-Restore. Сейчас - с минимальным набором 3rd-party (Tagadelic, Inline Tags, Site Menu, Pathauto, Transliteration) все вроде живет. Точнее, Transliteration не транслитерирует, но оно этого и с MySQL не делало, но всяких сообщений об ошибках и прочих безобразий пока нет, за исключением одного:

У меня на разных инсталляциях PostgreSQL стоит разный default client_charset. Где-то KOI8, где-то CP1251, но нигде не стоит UTF8 (базы все, естественно, в UTF). Это все по соображениям совместимости - много где живут скрипты многолетней давности и вставлять в каждый из них set client_charset мучительно.
Drupal о такой подлости не подозревает (MovableType - подозревает и выставляет), что лечится простым патчем:

drupal64.pgsql.diff.gz

Comments

Вообще-то в Postgres дефолтный клиент чарсет задается через переменную среды
PG_CLIENT_ENCODING. Которую можно прописать всем legacy скриптам в конфиге апача.

Солнце заходит на западе - вот я и не трогаю.

В том смысле, что не только апач, много скриптов standalone, крон опять же. Опять же перетаскивание скриптов между виртуалхостами будет интересным.

А то будут отличные грабли, когда php-fastcgi запускаемый из стартапа - работает, а потом я его перезапускаю из шелла и все портится.

От явной установки кодировки, тем более что друпал работает _только_ с UTF хуже не будет гарантированно.

У меня же сайту больше 10 лет, там столько всего наросло (да и сайт не один), трогать боюсь.

Сегодня патч принят в ядро http://drupal.org/cvs?commit=153411
Потребовался почти месяц...

Месяц - нормально.

Меня больше огорчает, что по другим моим патчам вообще нет движения никакого.