PostgreSQL 8.4.0 UTF conversion

Представим себе типичную ситуацию: есть таблица в 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 не понравился, слишком уж много дополнительных условий, в которых я не уверен.

Comments

а там для конвертирования стандартный iconv?
и koi8-r//TRANSLIT не хватает?

а еще в screen можно нажать ^A:utf-8

Там для конвертирования - свои таблицы. Для сортировки - системная локаль или ICU (для 8.4 ICU еще нету)

Но если в выходном алфавите нет выводимого символа - то это ошибка. В реальной жизни (с текстами в 1251 со всеми этими длинными тире и т.п. и эпизодическом выводе в KOI) - жуткий геморой.

И эту ошибку (ее выдачу) туда внесли намеренно, мои вялые попытки попросить сделать это конфигурируемым - провалились.

а зачем ему тогда в зависимостях iconv?

и эта, что значит систмная? его надо с локалью UTF8 запускать? или он сам ее у системы попросит?

А где это у него в зависимостях iconv?
lexa@home-gw:/usr/ports/databases# grep iconv postgresql*/Makefile
lexa@home-gw:/usr/ports/databases# -- пусто ---

А с локалью - она задается при initdb, дальше оно само setlocale сделает и все такое. Но не для преобразований символов, а для сортировки, вывода дат и т.п.

<q>А где это у него в зависимостях iconv?</q>
через libxml2

<q>А с локалью - она задается при initdb, дальше оно само setlocale сделает и все такое. Но не для преобразований символов, а для сортировки, вывода дат и т.п.</q>
для преобразований у меня screen есть

Не, ну это XML-ные дела. Можно без поддержки XML собрать, попустит.

У меня странный вопрос. А зачем в консоли кои-8? Давно уже ютф-8 туда добрался. Сам в консоли часто сижу, без проблем выборки делаю в ютф-8.

Вот такой я старомодный.

Но кроме консоли - у меня и пара-тройка сайтов в koi8.

А может все-таки похоронить стюардессу, в смысле эпизодический вывод в KOI8-R?
Работать, как все, в UTF-8. И пусть пользователи у которых 1251 страдают от символов, которым нет эквивалента.
Естественно, речь не идет о web-пользователях. В web-е тоже пора 8-байтовые кодировки похоронить.

Ну вот еще, сайт который много лет не трогал - вдруг начну трогать.

Ну, сайт можно не трогать. Трогать только .profile или .login. И немножко следить за руками, чтобы не навводить символов, не бывающих в CP1251. Или вообще, как делаю я, для каждой задачи запускать xterm в той локали, которая для этой задачи наиболее подходит. Должна эта база говорить в 1251, значит psql к ней мы будем в ru_RU.CP1251 запускать.

Я извиняюсь, но у меня сайт(ы) в koi8 и прям из базы так и берет. xterm ему не поможет.

Ну если сайт в KOI8, то откуда там может взяться символ, не имеющий эквивалента в ней же?
У меня как-то не было случаев, чтобы такие символы брались не через web-интерфейс (ну если не считать импорта из всяких rtf-ов через оный же залитых).

Или есть специальное приложение для наполнения сайта с GUI, куда массово cut'n'past-яд из офисных программ?

А сайт транслирует анонсы постов из блога. Напишу я в блоге про изделие 2 - и полсайта сайта нет...

Ну что ты защищаешь _глупое_ поведение БД? Я бы еще понял, если бы оно конфигурировалась, но гвоздями прибитая ошибка - это глупость.

Ибо сказано - не будьте слишком мудрыми, а будьте мудрыми в меру.
А то вот vim у меня проявляет "умное" поведение.
Полез я им опечатку в книге Розова править, запустив его с дуру в локали KOI8, так он мне половину пунктуации на вопросительные знаки заменил,

ты еще предложи линух поставить

Не, я восьмерку предложу поставить.

Я поставил. На девелоперской машине. Никакой разницы вообще не заметил.

и у нее магически появится UTF-8 в консоли?

Какой консоли? Ты о чем? Человек вроде работать собирался, а не сеть конфигурировать. Для конфигурирования сети русский язык не нужен вообще.

А после того, как сеть сконфигурирована, ты садишься за свою любимую рабочую станцию со своей любимой графической средой и в ней работаешь. В xterm utf-8 поддерживается чуть ли не с прошлого века.

А локаль UTF-8 была по-моему еще в 4-ке.

<q>Какой консоли? Ты о чем?</q>

ну эта, пост читаем, да?

<q>во многих случаях спец-символы не важны (скажем, при отладке в <b>консоли</b>)</q>

Ну, очень редко это будет настоящая консоль. Хотя возможны варианты, конечно.

Приятно видеть, что кто-то обеспокоен решением проблемы с posgresql и русскими кодировками. Сам столкнулся с подобной проблемой.

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

Add new comment