У постгресаа нет никакой дыры

Он использует системную локаль

Читайте man 5 locale man 7 locale

Ну так в этом и дыра. Это не очень хорошо. Именно из-за приведенной ссылки. нет в системной локали (или я не знаю) универсальной сортировки для unicode

"Дыра" в отстутствии ответов конечно, а не в этом. Это я имел ввиду

ENCODING='UTF8' LC_COLLATE='C' LC_CTYPE='C'

Ему надо немецкий+русский

А такой вопрос: это надо в одном и том же поле или в разных?

Ему надо немецкий+русский

Например. Мне вообще нужен универсальный. Это на самом деле сложная проблема. Но есть какие-то приемлимые решения например у MySQL. Но они туда захаркожены, что тоже не очень.

А такой вопрос: это надо в одном и том же поле или в разных?

В одном конечно.

за слова postgresql гавно тут банят ?

Тут просят аргументировать ?

Часто бывает "сам дурак"

Нехорошо флейм провоцировать

Нужно аргументировать недовольство тем или иным способом

На самом деле, я не сталкивался с мультиязычной сортировкой... Достаточно странная задача... Но вообще коллейшен стоит из трёх частей: язык, страна, кодировка. Язык или страна языка указывает, как будет отсортирован язык, как это приято в стране языка. Страна указывает на формат даты и разделителей целой и дробной части. у и кодировка понятно. Кодировка влияет на сортировку в последнюю очередь. Поэтому как решит эту проблему в рамках этой концепции, не совсем понятно. Можно сделать отдельный коллейт на поле (без смены кодировки, только язык_страна). Можно сделать коллейт на сортировку запроса... Врят ли вы в одной сортировке выводите разные языки. Хотя... В любом случае правильная сортировка будет только по заданному коллейту. Второй (третий и т.д.) языки будут сортироваться непредсказуемо. Ну и слепой перенос кейсов одной БД на другую - достаточно порочная практика. Вам надо либо пересмотреть задачу, либо более подробно её сформулировать...

Если в одном поле нужна разная сортировка, то вы можете создать несколько индексов с нужным COLLATE. Но опять же, не совсем понимаю как в одном поле объекдинить разные сортировки в одном запросе.

Да, индекс наверное идея

Если есть поле ланг, можно по лангам сортировать отдельно и делать union

тоже вариант.

Составной индекс по lang

А как с разными коллейтами быть в составном индексе?

Условные индексы, с условием по лангу - это другое дело

Как вариант https://russ.garrett.co.uk/2009/01/18/unicode-postgres/

На самом деле, я не сталкивался с мультиязычной сортировкой... Достаточно странная задача... Но вообще коллейшен стоит из трёх частей: язык, страна, кодировка. Язык или страна языка указывает, как будет отсортирован язык, как это приято в стране языка. Страна указывает на формат даты и разделителей целой и дробной части. у и кодировка понятно. Кодировка влияет на сортировку в последнюю очередь. Поэтому как решит эту проблему в рамках этой концепции, не совсем понятно. Можно сделать отдельный коллейт на поле (без смены кодировки, только язык_страна). Можно сделать коллейт на сортировку запроса... Врят ли вы в одной сортировке выводите разные языки. Хотя... В любом случае правильная сортировка будет только по заданному коллейту. Второй (третий и т.д.) языки будут сортироваться непредсказуемо. Ну и слепой перенос кейсов одной БД на другую - достаточно порочная практика. Вам надо либо пересмотреть задачу, либо более подробно её сформулировать...

Да ладно. Любой движок CMS, который не хочет никого мучать настройкой языка. Язык/кодировка хороши были в мире до Unicode, а с Unicode единственная сложность - сложить сортировки вместе. Давайте сейчас придумаю... вот. Делаю например сервис для телеграма. Не знаю, книжки в шаред медиа хочу библиотекой держать. Определять язык чатика или названия книги - иногда нерешаемая задача. А вот общий collation - вполне решаемая. Или вот у меня емагазин. Кастомеры со всего мира. Конечно каждый из них хочет сортировки так, чтобы у него глаза не вытекли. Собственно, тот же WordPress например _требует_ у MySQL вот этого _unicode_ci

Подождите... Вы определитесь, вы хотите просто сортировать или сортировать каждый язык по чётки правилам для умляутов и прочих экзотических буквиц? С обычной мультиязычной сортировкой по коду символов проблем вообще никаких.

Подождите... Вы определитесь, вы хотите просто сортировать или сортировать каждый язык по чётки правилам для умляутов и прочих экзотических буквиц? С обычной мультиязычной сортировкой по коду символов проблем вообще никаких.

я хочу среднее по больнице. вариант mysql с осознанием условности меня например удовлетворяет

http://stackoverflow.com/questions/9961795/utf8-postgresql-create-database-like-mysql-including-character-set-encoding-a

Так не пробовали?

А order by где ?

limit 1 там for presentation purpuoses

Так не пробовали?

ну так это more specific

Не понял...

Попробуйте de_DE вместо en_US если немецкий у вас в приоритете

А что у вас за приложение, если не секрет? Откуда взялась необходимость мультиязычной сортировки?

limit 1 там for presentation purpuoses

если описать кейс то, вобщем-то, будет больше шансов что разберутся и починят

а в каком месте непонятно? селект в постгресе возвращает не подходящие под селект строки, так бывает

А что у вас за приложение, если не секрет? Откуда взялась необходимость мультиязычной сортировки?

"Делаю например сервис для телеграма. Не знаю, книжки в шаред медиа хочу библиотекой держать. Определять язык чатика или названия книги - иногда нерешаемая задача. А вот общий collation - вполне решаемая. Или вот у меня емагазин. Кастомеры со всего мира. Конечно каждый из них хочет сортировки так, чтобы у него глаза не вытекли."

Кстати забавно, но вроде есть стандарт на Unicode Collation... На европейские языки он так и группирует - "Европейские языки"

Ну он-то ищет книжку на своём языке? Нет?

О, у меня сейчас стоит C.UTF-8 )

Ну он-то ищет книжку на своём языке? Нет?

а upper() lower()? а сортировка списка?

а в каком месте непонятно? селект в постгресе возвращает не подходящие под селект строки, так бывает

понятно, воспроизвести можете ?

или, хотябы, запрос не картинкой скинуть

воспроизвести могу, доступ у ребят из postgres pro поковырять - есть :)

сюда просто болью поделиться пришёл

а upper() lower()? а сортировка списка?

upper|lower какое отношение к сортировке имеют? Я про мультиязычную сортировку. Результат-то и список всегда на конкретном языке. На одном.

а upper() lower()? а сортировка списка?

Классы операторов text_pattern_ops, varchar_pattern_ops и bpchar_pattern_ops поддерживают индексы-B-деревья для типов text, varchar и char, соответственно. От стандартных классов операторов они отличаются тем, что сравнивают значения по символам, не применяя правила сортировки, определённые локалью. Благодаря этому они подходят для запросов с поиском по шаблону (с LIKE и регулярными выражениями POSIX), когда локаль базы данных не стандартная "C". Например, вы можете проиндексировать столбец varchar так: CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

upper|lower какое отношение к сортировке имеют? Я про мультиязычную сортировку. Результат-то и список всегда на конкретном языке. На одном.

они имеют отношения к collation

upper|lower какое отношение к сортировке имеют? Я про мультиязычную сортировку. Результат-то и список всегда на конкретном языке. На одном.

на UTF-8 )))

Классы операторов text_pattern_ops, varchar_pattern_ops и bpchar_pattern_ops поддерживают индексы-B-деревья для типов text, varchar и char, соответственно. От стандартных классов операторов они отличаются тем, что сравнивают значения по символам, не применяя правила сортировки, определённые локалью. Благодаря этому они подходят для запросов с поиском по шаблону (с LIKE и регулярными выражениями POSIX), когда локаль базы данных не стандартная "C". Например, вы можете проиндексировать столбец varchar так: CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

И зачем мне это?

на UTF-8 )))

Как кодировка влияет на результат upper|lower ?

воспроизвести могу, доступ у ребят из postgres pro поковырять - есть :)

PostgresPro - это хорошо, может сюда тоже стоит зарядить https://www.postgresql.org/account/submitbug/ ? )

Это к вопросу о сортировке. Она будет по символьная в "C".

Как кодировка влияет на результат upper|lower ?

Впрямую же

Это к вопросу о сортировке. Она будет по символьная в "C".

Зачем она мне такая?

а какая должна быть? у вас разные языки каким то образом сортироваться должны в одном поле?)

Впрямую же

Вы хотите сказать, что в разных кодировках результат upper|lower будет разный??? )))) А можно пример?

а какая должна быть? у вас разные языки каким то образом сортироваться должны в одном поле?)

У меня нет никаких языков. У меня UTF-8. Unicode. Для Unicode есть вполне себе условные универсальные правила сортировок

Вы хотите сказать, что в разных кодировках результат upper|lower будет разный??? )))) А можно пример?

Я приводил выше со словом Штрассе

У меня нет никаких языков. У меня UTF-8. Unicode. Для Unicode есть вполне себе условные универсальные правила сортировок

Тогда в чем вопрос? Вас не устраивает кодировка UTF8 в постгресе и сортировка?

А может это всё-таки от языка зависит, а не от кодировки?

Тогда в чем вопрос? Вас не устраивает кодировка UTF8 в постгресе и сортировка?

Мы ходим по кругу. Она там системная и _только_ more specific. А я хочу как в MySQL. Это удобно. Это соответствует большинству ожиданий и похоже это ISO 14651 (не уверен)

Мне кажется вся проблема вот в этом - "А я хочу как в MySQL."

я тоже хочу как в PostgreSQL массивы и хранимые процедуры, но приходится пользоваться другими инструментами в MySQL

Мне кажется вся проблема вот в этом - "А я хочу как в MySQL."

нет, проблема в том что в постгресе нет вот такой штуки из коробки https://en.wikipedia.org/wiki/Unicode_collation_algorithm

Все коллейшены можно посмотреть в pg_collation

Там все по классике. UCA нет

Да, есть в виде расширения http://www.public-software-group.org/pg_collkey

https://www.postgresql.org/message-id/kjqc4j%24gqa%242%40gonzo.reversiblemaps.ath.cx

Весь сыр-бор из за того что PostgreSQL использует collation libc?

???

Все хорошо работает :-)

Да, есть в виде расширения http://www.public-software-group.org/pg_collkey

Там 9.3 максимальная версия.

Значит надо писать англоязычные проекты и все :-)

Проблема решена

Да, есть в виде расширения http://www.public-software-group.org/pg_collkey

#UCA #unicode #collation А. Во. Вот кстати ответ. Спасибо

Кирилл молодец!

Весь сыр-бор из за того что PostgreSQL использует collation libc?

Да. Почему нет? На данный момент это странноватое решение. Хотя и unixway

Там 9.3 максимальная версия.

Чйорт. Ну тогда продолжаем

Кто нибудь прикручивал внешние таблицы в mapr hadoop?

Честно говоря чат превратился в очередной холивар PostgreSQL vs MySQL. И это печально.

Холиварить ненадо

Несварение от этого

Чйорт. Ну тогда продолжаем

А что продолжать? Надо либо свою локаль пилить, либо попытаться собрать расширение для свежей постгри :)

Чйорт. Ну тогда продолжаем

попробуйте скомпилить под свежую версию

Пилите Дима, они золотые :-)

Честно говоря чат превратился в очередной холивар PostgreSQL vs MySQL. И это печально.

Нет. Я реально хочу такого Collation. Это удобно. И это хорошо. И это правильно. И даже как оказалось ИСОшно. Вот разобрали вопрос и даже расширение нашли. Кому-то это поможет. Например мне

попробуйте скомпилить под свежую версию

Компиляция чего-либо в Linux то ещё занятие. Но видимо да

Компиляция чего-либо в Linux то ещё занятие. Но видимо да

Не сгущайте. У меня весь продакшен из исходников собран

То, что касается постгри. Дабы обновление оси не влияло на БД.

Лучше скажите что мне с мапром делать?