русификация

PostgreSQL 8.4.0 UTF conversion

lexa — Thu, 10 Sep 2009 15:36:29 +0000

Представим себе типичную ситуацию: есть таблица в UTF8, какой-то клиент вводит туда данные, работая, скажем, в кодировке windows-1251 и вводит, например, знак номера.

Потом другой клиент, работая уже в KOI8-R сделает по этой таблице SELECT и вместо результатов выборки увидит

ERROR: character такой-то of encoding "UTF8" has no equivalent in "KOI8R"

До версии PostgreSQL 8.1.4 выдавалось предупреждение, а три года назад это стало ошибкой, что сделало жизнь невыносимой: во многих случаях спец-символы не важны (скажем, при отладке в консоли), а работающих запросов хочется.

Начиная с 8.1.4 я делаю патчи для этой функциональности: вместо выдачи ошибки и прекращения запроса невыводимый символ просто меняется на пробел. Дошла очередь и до 8.4.0:

P.S. Своего мнения про 8.4 пока не имею, сформирую - напишу. Пока тестирую, в бой выставлять рановато. pg_migrator не понравился, слишком уж много дополнительных условий, в которых я не уверен.

Drupal + PostgreSQL = еще один патч

lexa — Thu, 09 Oct 2008 18:42:51 +0000

В процессе попыток использования Drupal 6.5 с PostgreSQL выявилась мелкая неприятность: интерфейс к постгресу не вполне правильно эскейпит строки со спецсимволами. Постгрес хочет, чтобы ему давали в виде E '\r\n', а Друпал дает без E. Пожелание это новое, появилось в какой-то из восьмых версий, на функциональность не влияет, но противно забивать лог неизвестно чем.

Патч прилагается:
Drupal
PostgreSQL
Web
Программирование

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

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

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

Лечение проблем LC_COLLATE при использовании UTF-8 в PostgreSQL под FreeBSD

lexa — Fri, 22 Feb 2008 10:39:22 +0000

Как я уже писал, при использовании UTF-8 в PostgreSQL под FreeBSD результат : сортировка русских букв неправильная (касается это только буквы ё). Причина - в кривой locale под FreeBSD (и Mac OS X).

Естественно, на эти грабли уже много раз наступали и для PostgreSQL 8.1 существуют , позволяющие использовать IBM-овскую в которой все сделано правильно для безумного количества языков.

Postgresql 8.3b1 UTF conversion patch

lexa — Tue, 30 Oct 2007 09:12:53 +0000

Я уже Патч для версий 8.1.4-8.2 можно найти по ссылке выше. Для 8.3-beta1 он не подходит, поэтому пришлось сделать новый:

Русификация MovableType состоит из таких шагов

Русификация дат
Русификация имен файлов для dirify
Перевод темплейтов и системных сообщений

Первые два пункта требуют правок кода, каковые правки и были сделаны. Все действия производились над MovableType 3.33

Postgresql 8.2, UTF8 и русские буквы

lexa — Sat, 02 Dec 2006 14:24:46 +0000

В отличие от вполне подходит и к 8.2

Postgresql 8.1.x и UTF-8

lexa — Wed, 01 Nov 2006 14:08:14 +0000

В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.

Тут же выяснилось, что ~~у этих криворуких уродов~~ таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.