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//TRANS
а там для конвертирования стандартный iconv?
и koi8-r//TRANSLIT не хватает?
а еще в screen можно нажать ^A:utf-8
Там для конвертирования - свои таблицы. Для сортировки - сис
Там для конвертирования - свои таблицы. Для сортировки - системная локаль или ICU (для 8.4 ICU еще нету)
Но если в выходном алфавите нет выводимого символа - то это ошибка. В реальной жизни (с текстами в 1251 со всеми этими длинными тире и т.п. и эпизодическом выводе в KOI) - жуткий геморой.
И эту ошибку (ее выдачу) туда внесли намеренно, мои вялые попытки попросить сделать это конфигурируемым - провалились.
а зачем ему тогда в зависимостях iconv? и эта, что значит с
а зачем ему тогда в зависимостях iconv?
и эта, что значит систмная? его надо с локалью UTF8 запускать? или он сам ее у системы попросит?
А где это у него в зависимостях iconv? lexa@home-gw:/usr/por
А где это у него в зависимостях iconv?
lexa@home-gw:/usr/ports/databases# grep iconv postgresql*/Makefile
lexa@home-gw:/usr/ports/databases# -- пусто ---
А с локалью - она задается при initdb, дальше оно само setlocale сделает и все такое. Но не для преобразований символов, а для сортировки, вывода дат и т.п.
<q>А где это у него в зависимостях iconv?</q> че
<q>А где это у него в зависимостях iconv?</q>
через libxml2
<q>А с локалью - она задается при initdb, дальше оно само setlocale сделает и все такое. Но не для преобразований символов, а для сортировки, вывода дат и т.п.</q>
для преобразований у меня screen есть
Не, ну это XML-ные дела. Можно без поддержки XML собрать, по
Не, ну это XML-ные дела. Можно без поддержки XML собрать, попустит.
У меня странный вопрос. А зачем в консоли кои-8? Давно уже ю
У меня странный вопрос. А зачем в консоли кои-8? Давно уже ютф-8 туда добрался. Сам в консоли часто сижу, без проблем выборки делаю в ютф-8.
Вот такой я старомодный. Но кроме консоли - у меня и пара-т
Вот такой я старомодный.
Но кроме консоли - у меня и пара-тройка сайтов в koi8.
А может все-таки похоронить стюардессу, в смысле эпизодическ
А может все-таки похоронить стюардессу, в смысле эпизодический вывод в KOI8-R?
Работать, как все, в UTF-8. И пусть пользователи у которых 1251 страдают от символов, которым нет эквивалента.
Естественно, речь не идет о web-пользователях. В web-е тоже пора 8-байтовые кодировки похоронить.
Ну вот еще, сайт который много лет не трогал - вдруг начну т
Ну вот еще, сайт который много лет не трогал - вдруг начну трогать.
Ну, сайт можно не трогать. Трогать только .profile или .logi
Ну, сайт можно не трогать. Трогать только .profile или .login. И немножко следить за руками, чтобы не навводить символов, не бывающих в CP1251. Или вообще, как делаю я, для каждой задачи запускать xterm в той локали, которая для этой задачи наиболее подходит. Должна эта база говорить в 1251, значит psql к ней мы будем в ru_RU.CP1251 запускать.
Я извиняюсь, но у меня сайт(ы) в koi8 и прям из базы так и б
Я извиняюсь, но у меня сайт(ы) в koi8 и прям из базы так и берет. xterm ему не поможет.
Ну если сайт в KOI8, то откуда там может взяться символ, не
Ну если сайт в KOI8, то откуда там может взяться символ, не имеющий эквивалента в ней же?
У меня как-то не было случаев, чтобы такие символы брались не через web-интерфейс (ну если не считать импорта из всяких rtf-ов через оный же залитых).
Или есть специальное приложение для наполнения сайта с GUI, куда массово cut'n'past-яд из офисных программ?
А сайт транслирует анонсы постов из блога. Напишу я в блоге
А сайт транслирует анонсы постов из блога. Напишу я в блоге про изделие 2 - и полсайта сайта нет...
Ну что ты защищаешь _глупое_ поведение БД? Я бы еще понял, если бы оно конфигурировалась, но гвоздями прибитая ошибка - это глупость.
Ибо сказано - не будьте слишком мудрыми, а будьте мудрыми в
Ибо сказано - не будьте слишком мудрыми, а будьте мудрыми в меру.
А то вот vim у меня проявляет "умное" поведение.
Полез я им опечатку в книге Розова править, запустив его с дуру в локали KOI8, так он мне половину пунктуации на вопросительные знаки заменил,
ты еще предложи линух поставить
ты еще предложи линух поставить
Не, я восьмерку предложу поставить.
Не, я восьмерку предложу поставить.
Я поставил. На девелоперской машине. Никакой разницы вообще
Я поставил. На девелоперской машине. Никакой разницы вообще не заметил.
и у нее магически появится UTF-8 в консоли?
и у нее магически появится UTF-8 в консоли?
Какой консоли? Ты о чем? Человек вроде работать собирался, а
Какой консоли? Ты о чем? Человек вроде работать собирался, а не сеть конфигурировать. Для конфигурирования сети русский язык не нужен вообще.
А после того, как сеть сконфигурирована, ты садишься за свою любимую рабочую станцию со своей любимой графической средой и в ней работаешь. В xterm utf-8 поддерживается чуть ли не с прошлого века.
А локаль UTF-8 была по-моему еще в 4-ке.
<q>Какой консоли? Ты о чем?</q> ну эта, пост чи
<q>Какой консоли? Ты о чем?</q>
ну эта, пост читаем, да?
<q>во многих случаях спец-символы не важны (скажем, при отладке в <b>консоли</b>)</q>
Ну, очень редко это будет настоящая консоль. Хотя возможны в
Ну, очень редко это будет настоящая консоль. Хотя возможны варианты, конечно.
Приятно видеть, что кто-то
Приятно видеть, что кто-то обеспокоен решением проблемы с posgresql и русскими кодировками. Сам столкнулся с подобной проблемой.
А в коммент к дискуссии - не проблема создавать всё с чистого листа на одинаковой кодировке. Проблема возникает когда подключаешься к рабочему проекту, начатому до тебя, с разными внешними модулями, типа веб-сайта и xls-отчетами...