|
|
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, уважаемые любители PostgreSQL! Возник неожиданный трабл с кодировками при переносе базы с Windous на MacOS Подскажите, если кто знает что нужно сделать В общем, я начинал проект на виндовом компе, установил Postgres 9.4, сконвертил БД из MySQL в постгрес, там выставилась каким-то непонятным образом LC_COLLATE = 'Russian_Russia.1251' Пока работал на винде, все было ок с сортировочками по текстовым полям, но вот как только решил перенести проект на рабочий ноут, возникли траблы: базу данных я перенес, но естественно, MacBook об 'Russian_Russia.1251' даже не подозревает. Попробовал поставить LC_COLLATE = 'ru_RU.UTF-8' или 'uk_UA.UTF-8' - тогда сортируется неправильно (например, украинский текст) - сортировка идет не по алфавиту, а по длине строк. Из-за чего это происходит - понятно, но что теперь делать - непонятно. Как переконвертить базу в UTF-8 ? P. S.: Бэкап/рестор делал через PGAdmin 3 backup/restore, может нужно sql-дамп сделать, потом его каким-нибудь эдитором в UTF-8 переконвертить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2016, 20:32 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2016, 22:02 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
вообще прикольно, PG чуть ли не единственная СУБД, которая не определяет свои локайлы... уж точно первая, которую я встречаю такую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2016, 19:54 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
MasterZivвообще прикольно, PG чуть ли не единственная СУБД, которая не определяет свои локайлы... уж точно первая, которую я встречаю такую. Классический Unix way. Не лезть не в свое дело (как то кеширование данных файловой системой или локали или файловая система сама или еще куча вещей которые Oracle самостоятельно реализует) а отдавать на откуп уже готовых инструментов операционной системы. У подхода есть свои плюсы и минусы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 03:47 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
Maxim BogukMasterZivвообще прикольно, PG чуть ли не единственная СУБД, которая не определяет свои локайлы... уж точно первая, которую я встречаю такую. Классический Unix way. Не лезть не в свое дело (как то кеширование данных файловой системой или локали или файловая система сама или еще куча вещей которые Oracle самостоятельно реализует) а отдавать на откуп уже готовых инструментов операционной системы. У подхода есть свои плюсы и минусы. плюсов чуть меньше чем 0. сдаётся, что наличие специального опса для LIKE--пригодного индекса -- это и есть один из хвалёных плюсов. там , где всем приличным людям хватает одного индекса -- нам нужно 2. что ещё нам поведают альтернативно ориентированные господа антиподы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 08:41 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
qwwq, приведи детальные примеры, когда нужно два индекса вместо одного, пож. если не сложно. не, минусов сильно дофига - непереносимость СУБД... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 09:23 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
qwwqMaxim Bogukпропущено... Классический Unix way. Не лезть не в свое дело (как то кеширование данных файловой системой или локали или файловая система сама или еще куча вещей которые Oracle самостоятельно реализует) а отдавать на откуп уже готовых инструментов операционной системы. У подхода есть свои плюсы и минусы. плюсов чуть меньше чем 0. сдаётся, что наличие специального опса для LIKE--пригодного индекса -- это и есть один из хвалёных плюсов. там , где всем приличным людям хватает одного индекса -- нам нужно 2. что ещё нам поведают альтернативно ориентированные господа антиподы ? Плюсов - не надо свою библиотеку локалей поддерживать. А это адское занятие посильное только очень крупным компаниям типа IBM. Это хуже чем timezones и сложнее. Ну и в общем ничего не мешает иметь сборку с IBM ICU либой если хочется переносимую реализацию локалей иметь (но ICU Это только UTF вроде а не весь зоопарк). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 09:48 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
MasterZivqwwq, приведи детальные примеры, когда нужно два индекса вместо одного, пож. если не сложно. не, минусов сильно дофига - непереносимость СУБД... Зато нет историй вида: https://mathiasbynens.be/notes/mysql-utf8mb4 (кстати предложенное решение через UTF32 с фиксом 4 байта на символ - оно "радостное" по обьему базы в конце). Поддерживать свои локали и collation - ад. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 10:21 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
MasterZivqwwq, приведи детальные примеры, когда нужно два индекса вместо одного, пож. если не сложно. не, минусов сильно дофига - непереносимость СУБД...1. мы с вами вместе не служили ? 2. повелительное наклонение применяйте где-нть в другом месте. за исключением этих 2-х пунктов -- всегда, когда нужны и разбиения алфавитных данных на диапазоны, и поиск по первым символам. Отсутствие отношения порядка на ops-нутых индексах мешает пользоваться ими при поиске в диапазоне. А не умение пользоваться не--опснутым индексом для LIKE 'blblbblb%' -- требует этого костыля (того же размера) в дополнение к неопснотому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 12:15 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
qwwq, извини, что ты обиделся, ничего дурного не имел в виду, там было "пож", это значит сокращение от "пожалуйста", пишу с телефона, поэтому иногда кратко. пример очень бы хотелось увидеть, если тебе будет не трудно и не лень... извини еще раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 12:21 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
ma3ypok, можно конечно пропатчить ICU. а можно удовлетвориться суррогатным решением : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. при сортировке криво учитывается регистр, т.е. сначала А-Я потом а-я и с Ё проблемы: идет раньше А (хотя кому она нужна эта Ё) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 14:50 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
dimonz80, Всем спасибо, в общем, за участие. Раскопал тему поглубже: MacOS просто-напросто сделал uk_UA.UTF-8/LC_COLLATE символической ссылкой на en_US.UTF-8/LC_COLLATE. Так что последний из приведенных примеров ничего не меняет. Это жесть - первый раз вижу такую херню у Apple. Был еще вариант с патчем ICU, но, я думаю, правильнее написать bugreport в Apple по поводу коллейтов Короче, психанул, вернулся на mariadb, благо таблиц пока еще не так много. Хотя Postgres меня во всем остальном очень даже устраивал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 17:25 |
|
||
|
Перекодировать базу или что делать?
|
|||
|---|---|---|---|
|
#18+
ma3ypokТак что последний из приведенных примеров ничего не меняет. Хотя бы по длине строк не сортирует. Для разработки хватает, а на продакшене все равно линукс или винда. Или у тебя FreeBSD?))) ma3ypokРаскопал тему поглубже: MacOS просто-напросто сделал uk_UA.UTF-8/LC_COLLATE символической ссылкой на en_US.UTF-8/LC_COLLATE. Да там все <LANG>.UTF-8/LC_COLLATE это софтлинки на la_LN.US-ASCII/LC_COLLATE. Копипаста с FreeBSD. ma3ypokЭто жесть - первый раз вижу такую херню у Apple. Был еще вариант с патчем ICU, но, я думаю, правильнее написать bugreport в Apple по поводу коллейтов В спортлото лучше писать) Эта проблема перекочевала из BSD вместе с однобайтовой функцией strcoll(). И переписывать стандартную библиотеку никто не спешит. Ищи что-то типа "UTF Collation FreeBSD", вроде проблему решает народ. Вот первое попавшееся решение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2016, 00:05 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39161595&tid=1997472]: |
0ms |
get settings: |
5ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
160ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 456ms |

| 0 / 0 |
