Добрый день, скажите LC_COLLATE ru_RU.UTF-8 и en_US.UTF-8 не отличаются?

Это системные locales, т.е. это полностью зависит от дистрибутива / libc.

1) Они отличаются, это разные объекты из pg_collation. 2) Сейчас в линуксе на glibc фактически последовательность символов одинаковая. 3) Судя по комментариям в /usr/share/i18n/locales/ru_RU -- некоторое время назад это было не так, буква й была какая-то особенная и в русской локали это исправляли.

У меня история такая, нужно перейти на новый сервер а на нем только en_US.UTF-8 (это облачный постгрес) на старом соответственно ru_RU.UTF-8. Я девелоперам предлагаю перед переездем на старом сервере сперва перейти на en_US.UTF-8 и протестить поиск. Они говорят да там разницы все равно нету.

Ну вот, например (относящаяся к делу) часть /usr/share/i18n/locales/ru_RU c одного из "старых" debian: LC_COLLATE copy "iso14651_t1" % iso14651_t1 is missing Ukrainian ghe collating-symbol <UKR-GHE> reorder-after <CYR-GZHE> <UKR-GHE> reorder-after <U0453> <U0491> <UKR-GHE>;<BAS>;<MIN>;IGNORE reorder-after <U0403> <U0490> <UKR-GHE>;<BAS>;<CAP>;IGNORE reorder-end END LC_COLLATE Если в данных этого символа нет и никогда не было — то в плане collate эти locales совпадают, получается. Но лучше проверьте на своих серверах — мало ли что. ;)

в примере речь о укринском. Да я кка админ как раз за то чтоб тестить ато после переезда прода будет поздно ) Как говориться как хотят так и будет, ток хотел предупредить какие возможно будут проблемы.

Я бы сказал, что надо тэстировать непосредственно на новых серверах. До переезда, ЕВПОЧЯ.

postgres=# create table test ( a text COLLATE "ru-RU-x-icu", b text COLLATE "en-US-x-icu"); CREATE TABLE postgres=# insert into test values ('ё', 'ё'), ('Z', 'Z'), ('Щ', 'Щ'); INSERT 0 3 postgres=# select * from test order by a; a | b ---+--- ё | ё Щ | Щ Z | Z (3 rows) postgres=# select * from test order by b; a | b ---+--- Щ | Щ Z | Z ё | ё (3 rows)

говорил, у ребят есть уверенность и не хотят телодвижений (тем более это еще и мой руководитель)

Так никто не мешает в базе с encoding UTF-8 хранить вообще любые символы, независимо то collation — откуда Вы знаете, что этого "Ukrainian ghe" там нет? ;) В общем, посмотрите соответствующие файлы на старом и новом серверах, да и всё.

пасиб протестирую

Судя по словам "облачный" и "только en_US.utf8" -- доступа в /usr/share/i18n/en_US там, скорее всего, не будет...

Покажите ребятам приведённый пример и пусть смотрят до просветления :) Поменяется порядок сортировки и сравнения символов. libc у меня под рукой нету, только icu, но смысл одинаковый.

все верно но я попробую таблицу с данными создать и отсортировать

пасиб еще раз, ща я на 2-х сервера протестирую

А это какая версия icu? У меня на 153.88 второе выдаёт хотя бы ilan=*> select * from test order by b; a | b ---+--- Z | Z ё | ё Щ | Щ

Не одинаковый, то-то и оно. Вот процитированный мной кусок — это вообще всё, что отличает libc collations (в этом дистрибутиве!) en_US.utf8 и ru_RU.utf8. А в других дистрибутивах может быть по-другому — см. https://t.me/pgsql/342321

То есть, я хочу сказать -- в разбивку русский-латинский-русский выглядит как совсем абзац, если честно.

А доступ под PostgreSQL superuser там тоже нет (иначе можно было бы "вытянуть" этот файл, т.к. у самого PostgreSQL должен быть к нему доступ)? А если нет — он же на чём-то (каком-то дистрибутиве) основан? Тогда можно было бы посмотреть эти файлы там.

Собирал с release-67-1 - 153.14.37

Sorry, 153.88 !

помоему на centosно не точно

Andrei St
сори что в виде фото , это en_US.UTF-8 (на облачно...

Это ни о чём не говорит в общем-то. Ну, кроме того, что СОВСЕМ большой проблемы с ё в этой glibc нет (но их и не было никогда в glibc).

postgres=# CREATE COLLATION "ru-RU-x-libc" ( locale = 'ru_RU', provider = "libc" ); CREATE COLLATION postgres=# CREATE COLLATION "en-US-x-libc" ( locale = 'en_US', provider = "libc" ); CREATE COLLATION postgres=# create table test2 ( a text COLLATE "ru-RU-x-libc", b text COLLATE "en-US-x-libc"); CREATE TABLE postgres=# insert into test2 values ('ё', 'ё'), ('Z', 'Z'), ('Щ', 'Щ'); INSERT 0 3 postgres=# select * from test order by a; a | b ---+--- ё | ё Щ | Щ Z | Z (3 rows) postgres=# select * from test order by b; a | b ---+--- Щ | Щ Z | Z ё | ё (3 rows)

на ru_RU.UTF-8 аналогичная сотрировка, при создании таблицы я не указывал COLLATE

Я про то, что glibc collation меняло кучу других букв -- й, украинское это Gzhe, в общем проверить без большого датасета вряд ли получится.

А, перепутал селекты :) postgres=# select * from test2 order by a; a | b ---+--- Щ | Щ Z | Z ё | ё (3 rows) postgres=# select * from test2 order by b; a | b ---+--- Щ | Щ Z | Z ё | ё (3 rows)

Windows?

Ага.

Выглядит как-то сломанно.

Я test забыл на test2 поменять, когда тыкал в истории select * (говорил же себе - дропай тестовое барахло сразу после использования!)

Более логично, но тожэ сломанно!

А теперь мне интересно, а что сломано-то?

А вот то же самое не в windows (и не debian): https://www.db-fiddle.com/f/fsnTxAqMYatWfJChUGvozX/0 В общем, от системы это зависит, так что ещё пойди проверь, если нет доступа к FS.

Русская-латинская-русская. Притом вторая русская явно меньшэ первой. Вообще что-то не представляю, какой там порядок.

test=# CREATE COLLATION "ru-RU-x-libc" ( locale = 'ru_RU', provider = "libc"); ERROR: encoding "UTF8" does not match locale "ru_RU" Это WSL под той же windows. А я думал, с ICU мороки много :)

alpine?

wsl вообще не зависит от того, что "под windows". Только от дистрибутива (и какие библиотеки в нём лежат). Была бы убунта -- было бы как обычно всё.

Да я на всякий случай уточнил. Короче, icu при всех недостатках выглядит единообразнее.

Спасибо! Не знал.