23.2. Поддержка правил сортировки #

Правила сортировки позволяют устанавливать порядок сортировки и особенности классификации символов в отдельных столбцах или даже при выполнении отдельных операций. Это смягчает последствия того, что параметры базы данных LC_COLLATE и LC_CTYPE невозможно изменить после её создания.

23.2.1. Основные понятия #

Концептуально, каждое выражение с типом данных, к которому применяется сортировка, имеет правила сортировки. (Встроенными сортируемыми типами данных являются text, varchar, и char. Типы, определяемые в базе пользователем, могут также быть отмечены как сортируемые, и, конечно, домен на основе сортируемого типа данных является сортируемым.) Если выражение содержит ссылку на столбец, правила сортировки выражения определяются правилами сортировки столбца. Если выражение — константа, правилами сортировки являются стандартные правила для типа данных константы. Правила сортировки более сложных выражений являются производной от правил сортировки входящих в него частей, как описано ниже.

Правилами сортировки выражения могут быть правила сортировки «по умолчанию», что означает использование параметров локали, установленных для базы данных. Также возможно, что правила сортировки выражения могут не определиться. В таких случаях операции упорядочивания и другие операции, для которых необходимы правила сортировки, завершатся с ошибкой.

Когда база данных должна выполнить упорядочивание или классификацию символов, она использует правила сортировки выполняемого выражения. Это происходит, к примеру, с предложениями ORDER BY и такими вызовами функций или операторов как <. Правила сортировки, которые применяются в предложении ORDER BY, это просто правила ключа сортировки. Правила сортировки, применяемые к вызову функции или оператора, определяются их параметрами, как описано ниже. В дополнение к операциям сравнения, правила сортировки учитываются функциями, преобразующими регистр символов, такими как lower, upper, и initcap; операторами поиска по шаблону; и функцией to_char и связанными с ней.

При вызове функции или оператора правило сортировки определяется в зависимости от того, какие правила заданы для аргументов во время выполнения данной операции. Если результатом вызова функции или оператора является сортируемый тип данных, правила сортировки также используются во время разбора как определяемые правила сортировки функции или выражения оператора, когда для внешнего выражения требуется знание правил сортировки.

Определение правил сортировки выражения может быть неявным или явным. Это отличие влияет на то, как комбинируются правила сортировки, когда несколько разных правил появляются в выражении. Явное определение правил сортировки возникает, когда используется предложение COLLATE; все прочие варианты являются неявными. Когда необходимо объединить несколько правил сортировки, например, в вызове функции, используются следующие правила:

  1. Если для одного из выражений-аргументов правило сортировки определено явно, то и для других аргументов явно задаваемое правило должно быть тем же, иначе возникнет ошибка. В случае присутствия явного определения правила сортировки, оно становится результирующим для всей операции.

  2. В противном случае все входные выражения должны иметь одни и те же неявно определяемые правила сортировки или правила сортировки по умолчанию. Если присутствуют какие- либо правила сортировки, отличные от заданных по умолчанию, получаем результат комбинации правил сортировки. Иначе результатом станут правила сортировки, заданные по умолчанию.

  3. Если среди входных выражений есть конфликтующие неявные правила сортировки, отличные от заданных по умолчанию, тогда комбинация рассматривается как имеющая неопределённые правила сортировки. Это не является условием возникновения ошибки, если вызываемой конкретной функции не требуются данные о правилах сортировки, которые ей следует применить. Если же такие данные требуются, это приведёт к ошибке во время выполнения.

В качестве примера рассмотрим данное определение таблицы:

CREATE TABLE test1 (
    a text COLLATE "ru_RU",
    b text COLLATE "es_ES",
    ...
);

Затем в

SELECT a < 'foo' FROM test1;

выполняется оператор сравнения < согласно правилам ru_RU, так как выражение объединяет неявно определяемые правила сортировки с правилами, заданными по умолчанию. Но в

SELECT a < ('foo' COLLATE "fr_FR") FROM test1;

сравнение выполняется с помощью правил fr_FR, так как явное определение правил сортировки переопределяет неявное. Кроме того, в запросе

SELECT a < b FROM test1;

анализатор запросов не может определить, какое правило сортировки использовать, поскольку столбцы a и b имеют конфликтующие неявные правила сортировки. Так как оператору < требуется знать, какое правило использовать, это приведёт к ошибке. Ошибку можно устранить, применив явное указание правил сортировки к любому из двух входных выражений. Например:

SELECT a < b COLLATE "ru_RU" FROM test1;

либо эквивалентное ему

SELECT a COLLATE "ru_RU" < b FROM test1;

С другой стороны, следующее выражение схожей структуры

SELECT a || b FROM test1;

не приводит к ошибке, поскольку для оператора || правила сортировки не имеют значения, так как результат не зависит от сортировки.

Правила сортировки, назначенные функции или комбинации входных выражений оператора, также могут быть применены к функции или результату оператора, если функция или оператор возвращают результат сортируемого типа данных. Так, в

SELECT * FROM test1 ORDER BY a || 'foo';

упорядочение будет происходить согласно правилам ru_RU. Но данный запрос:

SELECT * FROM test1 ORDER BY a || b;

приводит к ошибке, потому что, даже если оператору || не нужно знать правила сортировки, предложению ORDER BY это требуется. Как было сказано выше, конфликт может быть разрешён при помощи явного указания правил сортировки:

SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";

23.2.2. Управление правилами сортировки #

Правила сортировки представляют собой объект схемы SQL, который сопоставляет SQL-имя с локалью, реализуемой библиотекой, установленной в операционной системе. В определении правила сортировки задаётся провайдер, то есть библиотека, реализующая правило сортировки. Стандартный провайдер с именем libc использует системную библиотеку C и предоставляет её локали. Именно эти локали используются большинством утилит операционной системы. Также есть провайдер icu, который использует внешнюю библиотеку ICU. Локали ICU можно использовать, только если поддержка ICU была включена в конфигурации сборки Postgres Pro.

Правило сортировки, предоставляемое провайдером libc, сопоставляется с комбинацией параметров LC_COLLATE и LC_CTYPE, которую может принять системный вызов setlocale(). (Основная цель правила сортировки — настроить параметр LC_COLLATE, который управляет упорядочиванием символов. Однако на практике редко требуется иметь значение LC_CTYPE, отличное от LC_COLLATE, поэтому удобнее объединить их в одну сущность, и не создавать отдельную инфраструктуру для указания LC_CTYPE в выражениях.) Правила сортировки libc также связаны с кодировкой набора символов (см. Раздел 23.3). Одно и то же имя правила сортировки может существовать для разных кодировок.

Объект правила сортировки, предоставляемой провайдером icu, сопоставляется с именованным сортировщиком, реализуемым библиотекой ICU. ICU не поддерживает различные характеристики «collate» и «ctype», так что они всегда совпадают. Кроме того, правила сортировки ICU не зависят от кодировки, так что в базе данных будет всего одно правило сортировки ICU с определённым именем.

23.2.2.1. Стандартные правила сортировки #

На всех платформах поддерживаются следующие правила сортировки:

unicode

Это правило сортировки использует Алгоритм сортировки Unicode с Таблицей сортировки символов Unicode по умолчанию. Оно доступно во всех кодировках. Для его использования требуется поддержка ICU, и поведение зависит от того, какая версия ICU используется в данной сборке Postgres Pro. (Это правило сортировки работает так же, как и корневая локаль ICU; см. und-x-icu («undefined», неопределённая).)

ucs_basic

С этим стандартным правилом SQL сортировка выполняется по кодам символов Unicode, а не в порядке, принятом в естественном языке, и только символы ASCII от «A» до «Z» обрабатываются как буквы. Такое поведение эффективно и стабильно работает во всех версиях. Правило доступно только для кодировки UTF8. (Это правило сортировки работает так же, как и правило C локали libc в кодировке UTF8.)

pg_c_utf8

С этим правилом сортировка выполняется по кодам символов Unicode, а не в порядке, принятом в естественном языке. Для функций lower, initcap и upper используется простое преобразование регистра Unicode. Для сопоставления шаблонов (включая регулярные выражения) используется совместимый с POSIX вариант Unicode (Совместимость). Такое поведение эффективно и стабильно в основной версии Postgres Pro. Данное правило сортировки доступно только для кодировки UTF8.

C (равнозначно POSIX)

Правила сортировки C и POSIX основаны на «традиционном» поведении C. С этими правилами сортировка выполняется по байтовым значениям, а не в порядке, принятом в естественном языке, и только символы ASCII от «A» до «Z» обрабатываются как буквы. Поведение эффективно и стабильно во всех версиях для данной кодировки базы данных, но может отличаться для других кодировок.

default

С правилом сортировки default выбирается локаль, указанная при создании базы данных.

Поддержка дополнительных правил сортировки зависит от операционной системы, а эффективность и стабильность этих правил — от провайдера, его версии и локали.

23.2.2.2. Предопределённые правила сортировки #

Если операционная система поддерживает использование нескольких локалей в одной программе (newlocale и связанные функции) или включена поддержка ICU, то при инициализации кластера баз данных программа initdb наполняет системный каталог pg_collation информацией обо всех локалях, которые обнаруживает в этот момент в операционной системе.

Для просмотра всех имеющихся локалей выполните запрос SELECT * FROM pg_collation или команду \dOS+ в psql.

23.2.2.2.1. Правила сортировки libc #

Например, операционная система может предоставлять локаль с именем ru_RU.utf8 При этом программа initdb создаст правило сортировки с именем ru_RU.utf8 для кодировки UTF8, в котором LC_COLLATE и LC_CTYPE будут равны ru_RU.utf8. Также будет создано правило сортировки с именем без метки .utf8 в окончании. Таким образом, вы можете использовать это правило под именем ru_RU, которое будет компактнее и не будет зависеть от кодировки. Заметьте, что изначальный набор имён правил сортировки тем не менее зависит от платформы.

Стандартный набор правил сортировки, предоставляемый провайдером libc, сопоставляется непосредственно с локалями, установленными в операционной системе (их можно просмотреть с помощью команды locale -a). В случаях, когда у правила сортировки libc должны быть различные значения LC_COLLATE и LC_CTYPE, или когда в операционную систему после инициализации СУБД устанавливаются новые локали, создать новое правило сортировки можно с помощью команды CREATE COLLATION. Новые локали операционной системы можно также импортировать в массовом порядке, воспользовавшись функцией pg_import_system_collations().

В любой базе данных имеют значение только те правила сортировки, которые используют кодировку этой базы данных. Прочие записи в pg_collation игнорируются. Таким образом, усечённое имя правил сортировки, такое как ru_RU, может считаться уникальным внутри данной базы данных, даже если бы оно не было уникальным глобально. Использование усечённого имени сортировки рекомендуется, так как при переходе на другую кодировку базы данных придётся выполнить на одно изменение меньше. Однако следует помнить, что правила сортировки default, C и POSIX можно использовать независимо от кодировки базы данных.

В Postgres Pro предполагается, что отдельные объекты правил сортировки несовместимы, даже когда они имеют идентичные свойства. Так, например,

SELECT a COLLATE "C" < b COLLATE "POSIX" FROM test1;

выведет сообщение об ошибке, несмотря на то, что поведение правил сортировки C и POSIX идентично. По этой причине смешивать усечённые и полные имена правил сортировки не рекомендуется.

23.2.2.2.2. Правила сортировки ICU #

С ICU не представляется разумным перечислять все возможные имена локалей. ICU использует для локалей определённую схему именования, но имён локалей может быть гораздо больше, чем собственно различных локалей. Программа initdb, используя API ICU, извлекает список различных локалей и наполняет начальный набор правил в базе данных. Правила сортировки провайдера ICU создаются с именами, включающими метку языка в формате BCP 47 и указание расширения «для частного использования» (-x-icu), для отличия от локалей libc.

Например, могут быть созданы такие правила сортировки:

ru-x-icu #

Русское правило сортировки, стандартный вариант

ru-UA-x-icu #

Русское правило сортировки для Украины, стандартный вариант

(Например, существует правило ru-RU-x-icu, но на момент написания документации оно равнозначно правилу ru-x-icu.)

und-x-icu («undefined», неопределённая) #

«Корневое» правило сортировки ICU. Оно устанавливает разумный языконезависимый порядок сортировки.

Некоторые (редко используемые) кодировки не поддерживаются ICU. Когда база имеет одну из таких кодировок, записи правил сортировки ICU в pg_collation игнорируются. При попытке использовать их будет выдана ошибка с сообщением вида «правило сортировки "de-x-icu" для кодировки "WIN874" не существует».

23.2.2.3. Создание новых правил сортировки #

Если стандартных и предопределённых правил сортировки недостаточно, пользователи могут создавать собственные правила сортировки, используя команду SQL CREATE COLLATION.

Стандартные и предопределённые правила сортировки находятся в схеме pg_catalog, как и все предопределённые объекты. Пользовательские правила сортировки должны создаваться в пользовательских схемах. Помимо прочего, это полезно тем, что их будет выгружать pg_dump.

23.2.2.3.1. Правила сортировки libc #

Новые правила сортировки libc могут создаваться так:

CREATE COLLATION russian (provider = libc, locale = 'ru_RU');

Точные значения, которые могут допускаться в предложении locale в этой команде, зависят от операционной системы. В Unix-подобных системах их список выдаёт команда locale -a.

Так как предопределённый набор правил сортировки libc уже включает все правила сортировки, определённые в операционной системе в момент инициализации базы данных, необходимость создавать новые правила вручную обычно не возникает. Такая потребность может возникнуть, когда нужно сменить систему именования (в этом случае см. Подраздел 23.2.2.3.3) либо когда операционная система была обновлена и в ней появились новые определения локалей (в этом случае см. pg_import_system_collations()).

23.2.2.3.2. Правила сортировки ICU #

Правила сортировки ICU могут быть созданы следующим образом:

CREATE COLLATION german (provider = icu, locale = 'de-DE');

Имена локалей ICU указываются как языковые метки BCP 47, но также принимается большинство имён локалей в стиле libc. Если это возможно, имена локалей в стиле libc преобразуются в языковые метки.

Для новых правил сортировки ICU допускается настройка поведения путём указания параметров в языковой метке. За подробным описанием и примерами обратитесь к Подразделу 23.2.3.

23.2.2.3.3. Копирование правил сортировки #

Команда CREATE COLLATION может также создать новое правило сортировки из существующего, что может быть полезно для использования имён, независимых от операционных систем, создания имён для совместимости или использования правил сортировки ICU под более понятными именами. Например:

CREATE COLLATION russian FROM "ru_RU";
CREATE COLLATION french FROM "fr-x-icu";

23.2.2.4. Недетерминированные правила сортировки #

Правило сортировки может быть либо детерминированным, либо недетерминированным. С детерминированными правилами сортировки используются детерминированные сравнения, что означает, что сроки считаются равными, только если они состоят из одинаковой последовательности байтов. Недетерминированное же сравнение может признать равными строки, состоящие и из разных байтов. Обычно это требуется при сравнении без учёта регистра или ударения, а также при сравнении строк в различных нормальных формах Unicode. Как именно будут реализованы подобные сравнения, определяется провайдером правил сортировки; флаг детерминированности только отмечает, будет ли вопрос равенства решаться побайтовым сравнением. Подробнее сопутствующая терминология описывается в Техническом стандарте Unicode 10.

Чтобы создать недетерминированное правило сортировки, укажите свойство deterministic = false в команде CREATE COLLATION, например так:

CREATE COLLATION ndcoll (provider = icu, locale = 'und', deterministic = false);

В данном примере будет использоваться стандартное правило сортировки Unicode в недетерминированном режиме. В частности, это позволит корректно сравнивать строки в различных нормальных формах. Для более интересных применений задействуются специальные возможности ICU, рассмотренные выше. Например:

CREATE COLLATION case_insensitive (provider = icu, locale = 'und-u-ks-level2', deterministic = false);
CREATE COLLATION ignore_accents (provider = icu, locale = 'und-u-ks-level1-kc-true', deterministic = false);

Все стандартные и предопределённые правила сортировки являются детерминированными, и так же детерминированными по умолчанию создаются пользовательские правила. Недетерминированные правила сортировки обеспечивают более «правильное» поведение, особенно в части использования всех возможностей Unicode и обработки множества особых случаев, но они имеют и ряд недостатков. Прежде всего, их применение отрицательно сказывается на производительности. Заметьте в частности, что в B-деревьях с недетерминированным правилами не будет производиться исключение дубликатов. К тому же с недетерминированными правилами сортировки невозможны некоторые операции, например, поиск по шаблону. Поэтому применять их следует только тогда, когда в этом есть явная необходимость.

Подсказка

Для эффективной обработки текста в различных формах нормализации Unicode также можно использовать функции/выражения normalize и is normalized, позволяющие предварительно обработать или проверить строки, и не прибегать к использованию недетерминированных правил сортировки. Однако каждый подход имеет свои минусы.

23.2.3. Пользовательские правила сортировки ICU #

ICU позволяет управлять поведением правил сортировки путём определения новых правил с параметрами, заданными в виде части языковой метки. Эти параметры могут изменить порядок сортировки в соответствии с различными потребностями. Например:

-- игнорировать различия в диакритических знаках и регистре
CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1');
SELECT 'Å' = 'A' COLLATE ignore_accent_case; -- true
SELECT 'z' = 'Z' COLLATE ignore_accent_case; -- true

-- буквы в верхнем регистре идут перед буквами в нижнем
CREATE COLLATION upper_first (provider = icu, locale = 'und-u-kf-upper');
SELECT 'B' < 'b' COLLATE upper_first; -- true

-- сортировать последовательности цифр по числовым значениям и игнорировать знаки пунктуации
CREATE COLLATION num_ignore_punct (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-kn');
SELECT 'id-45' < 'id-123' COLLATE num_ignore_punct; -- true
SELECT 'w;x*y-z' = 'wxyz' COLLATE num_ignore_punct; -- true

Многие доступные параметры описаны в Подразделе 23.2.3.2, а дополнительную информацию можно найти в Подразделе 23.2.3.5.

23.2.3.1. Уровни сравнения ICU #

Сравнение двух строк (сортировка) в ICU определяется многоуровневым процессом, в котором текстовые признаки сгруппированы в «уровни». Обработка каждого уровня зависит от параметрами правил сортировки. На более высоких уровнях выполняется более детальное сравнение.

Таблица 23.1 показывает, какие различия в текстовых признаках имеют приоритет при сравнении на данном уровне. Символ Unicode U+2063 является невидимым разделителем и, как видно из таблицы, игнорируется на всех уровнях сравнения ниже identic.

Таблица 23.1. Уровни сортировки ICU

УровеньОписание'f' = 'f''ab' = U&'a\2063b''x-y' = 'x_y''g' = 'G''n' = 'ñ''y' = 'z'
level1Базовый символtruetruetruetruetruefalse
level2Диакритические знакиtruetruetruetruefalsefalse
level3Регистры/Вариантыtruetruetruefalsefalsefalse
level4Пунктуация[a]truetruefalsefalsefalsefalse
identicВсеtruefalsefalsefalsefalsefalse

[a] только с ka-shifted; см. Таблицу 23.2


На каждом уровне, даже при выключенной полной нормализации, выполняется базовая нормализация. Например, 'á' может состоять из кодов символов U&'\0061\0301' или одного кода символа U&'\00E1', и эти последовательности будут считаться равными даже на уровне identic. Чтобы учитывались любые различия в представлениях кодов символов, используйте параметры правил сортировки, созданные с параметром deterministic, который имеет значение true.

23.2.3.1.1. Примеры уровней сортировки #
CREATE COLLATION level3 (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-level3');
CREATE COLLATION level4 (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-level4');
CREATE COLLATION identic (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-identic');

-- невидимый разделитель, игнорируемый на всех уровнях кроме identic
SELECT 'ab' = U&'a\2063b' COLLATE level4; -- true
SELECT 'ab' = U&'a\2063b' COLLATE identic; -- false

-- знаки пунктуации игнорируются на уровне 3, но не на уровне 4
SELECT 'x-y' = 'x_y' COLLATE level3; -- true
SELECT 'x-y' = 'x_y' COLLATE level4; -- false

23.2.3.2. Параметры правил сортировки для локали ICU #

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

Таблица 23.2. Параметр правил сортировки ICU

КлючЗначенияПо умолчаниюОписание
coemoji, phonebk, standard, ...standardТип правил сортировки. Обратитесь к Подразделу 23.2.3.5 для получения дополнительной информации.
kanoignore, shiftednoignoreЕсли установлено значение shifted, некоторые символы (например, знаки препинания или пробел) игнорируются при сравнении. Чтобы ключ ks применялся, он должен быть установлен на уровне level3 или ниже. Установите ключ kv, чтобы указать игнорируемые классы символов.
kbtrue, falsefalseОбратное сравнение для различий уровня 2. Например, с локалью und-u-kb 'àe' окажется перед 'aé'.
kctrue, falsefalse

Относит случай к «уровню 2.5», который находится между диакритическими знаками и другими признаками уровня 3.

Если установлено значение true, а для ks установлено значение level1, диакритические знаки будут игнорироваться, но будет учитываться регистр.

kfupper, lower, falsefalseЕсли установлено значение upper, символы в верхнем регистре идут перед символами в нижнем, а если lower — наоборот. Если установлено значение false, сортировка зависит от правил локали.
kntrue, falsefalseЕсли установлено значение true, последовательности цифр сортируются по числовым значениям. Например, 'id-45' окажется перед 'id-123'.
kktrue, falsefalse

Включает полную нормализацию, может повлиять на производительность. Базовая нормализация выполняется, даже если установлено значение false. Локали для языков, требующих полной нормализации, обычно включают её по умолчанию.

В некоторых случаях важна полная нормализация, например, когда к одному символу применяется несколько диакритических знаков. Например, последовательности кодов символов U&'\0065\0323\0302' и U&'\0065\0302\0323' представляют собой e с циркумфлексом и точками снизу, применяемыми в разном порядке. При включённой полной нормализации эти последовательности кодов символов рассматриваются как равные, в противном случае они неравны.

krspace, punct, symbol, currency, digit, id_скрипта 

Принимает одно или несколько допустимых значений или любой id_скрипта BCP 47, например latn («латынь») или grek («греческий»). Несколько значений разделяются знаком «-».

Переопределяет упорядочение классов символов: символы, принадлежащие более раннему классу в списке, указываются перед символами, принадлежащими более позднему классу в списке. Например, значение digit-currency-space (как часть языковой метки, такой как und-u-kr-digit-currency-space) сортирует знаки препинания перед цифрами и пробелами.

kslevel1, level2, level3, level4, identiclevel3Чувствительность (или «степень») при сравнении, где на уровне на уровне identic большинство различий учитывается, а на уровне level1 — игнорируется. За подробностями обратитесь к Таблице 23.1.
kvspace, punct, symbol, currencypunctКлассы символов игнорируются при сравнении на уровне 3. Установка следующего значения в списке включает все предыдущие, например symbol также включает punct и space в символах, которые следует игнорировать. Чтобы работать, ключ ka должен иметь значение shifted, а ключ ks — значение level3 или ниже.

Значения по умолчанию могут зависеть от локали. Приведённая выше таблица не является полной. Обратитесь к Подразделу 23.2.3.5 для получения дополнительной информации.

Примечание

В случае со многими параметрами правил сортировки, чтобы конкретный параметр имел желаемый эффект, нужно создавать правила сортировки с параметром deterministic, для которого задано значение false (см. Подраздел 23.2.2.4). Кроме того, некоторые параметры вступают в силу только тогда, когда для ключа ka установлено значение shifted (см. Таблицу 23.2).

23.2.3.3. Примеры параметров правил сортировки #

CREATE COLLATION "de-u-co-phonebk-x-icu" (provider = icu, locale = 'de-u-co-phonebk'); #

Немецкое правило сортировки с порядком, принятым для телефонной книги

CREATE COLLATION "und-u-co-emoji-x-icu" (provider = icu, locale = 'und-u-co-emoji'); #

Корневое правило с сортировкой эмодзи, соответствующее техническому стандарту Unicode №51

CREATE COLLATION latn_cyrl (provider = icu, locale = 'ru-RU-u-kr-latn-cyrl'); #

Правило сортировки, с которым латинские буквы идут перед буквами кириллицы. (По умолчанию сначала идут буквы кириллицы.)

CREATE COLLATION upperfirst (provider = icu, locale = 'ru-RU-u-kf-upper'); #

Правило сортировки, с которым буквы в верхнем регистре идут перед буквами в нижнем. (По умолчанию сначала идут буквы в нижнем регистре.)

CREATE COLLATION special (provider = icu, locale = 'ru-RU-u-kf-upper-kr-latn-cyrl'); #

Правило, в котором сочетаются предыдущие свойства.

23.2.3.4. Правила для сортировки ICU #

Если вышеуказанных параметров правил сортировки недостаточно, порядок элементов сортировки можно изменить с помощью особых правил сортировки, синтаксис которых подробно описан в https://unicode-org.github.io/icu/userguide/collation/customization/.

В этом простом примере создаётся правило сортировки на основе корневой локали с дополнительным условием сортировки:

CREATE COLLATION custom (provider = icu, locale = 'und', rules = '&V << w <<< W');

Так буква «W» окажется осле «V», но это условие рассматривается как второстепенное отличие, подобное диакритическому знаку. Такие правила содержатся в определениях локалей некоторых языков. (Конечно, если определение локали уже содержит нужные правила, их не нужно снова указывать явно.)

Ниже показан более сложный пример. Следующий оператор задаёт правило сортировки с именем ebcdic, при использовании которого символы US-ASCII сортируются в порядке, соответствующем кодировке EBCDIC.

CREATE COLLATION ebcdic (provider = icu, locale = 'und',
rules = $$
& ' ' < '.' < '<' < '(' < '+' < \|
< '&' < '!' < '$' < '*' < ')' < ';'
< '-' < '/' < ',' < '%' < '_' < '>' < '?'
< '`' < ':' < '#' < '@' < \' < '=' < '"'
<*a-r < '~' <*s-z < '^' < '[' < ']'
< '{' <*A-I < '}' <*J-R < '\' <*S-Z <*0-9
$$);

SELECT c
FROM (VALUES ('a'), ('b'), ('A'), ('B'), ('1'), ('2'), ('!'), ('^')) AS x(c)
ORDER BY c COLLATE ebcdic;
 c
---
 !
 a
 b
 ^
 A
 B
 1
 2

23.2.3.5. Ссылки на внешние ресурсы про ICU #

Этот раздел (Подраздел 23.2.3) представляет собой лишь краткий обзор поведения ICU и языковых меток. Технические подробности, дополнительные параметры и новое поведение описаны в следующих документах: