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

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

Понятия

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

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

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

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

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

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

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

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

Например, рассмотрим следующее определение таблицы:

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

Тогда в запросе

SELECT a < 'foo' FROM test1;

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

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

сравнение производится по правилам fr_FR, так как явная спецификация правила сортировки переопределяет неявную. Кроме того, учитывая запрос

SELECT a < b FROM test1;

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

SELECT a < b COLLATE "de_DE" FROM test1;

или эквивалентно

SELECT a COLLATE "de_DE" < b FROM test1;

С другой стороны, структурно похожий случай

SELECT a || b FROM test1;

не вызывает ошибку, потому что оператору || нет необходимости учитывать правила сортировки: его результат всегда один и тот же независимо от используемого правила сортировки.

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

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

упорядочение будет выполнено в соответствии с правилами de_DE. Однако следующий запрос:

SELECT * FROM test1 ORDER BY a || b;

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

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

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

Правило сортировки – это объект схемы SQL, который отображает имя SQL на локали, предоставляемые библиотеками, установленными в операционной системе. Определение правила сортировки содержит поставщика, который указывает, какая библиотека предоставляет данные о локалях. Одним стандартным именем поставщика является libc, который использует локали, предоставленные стандартной библиотекой языка программирования С операционной системы. Эти локали используются большинством инструментов, предоставляемых операционной системой. Другим поставщиком является icu, использующий внешнюю библиотеку ICU. Локали ICU могут использоваться только в том случае, если поддержка ICU была настроена при сборке PostgreSQL.

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

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

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

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

unicode

: Это стандартное правило сортировки SQL сортирует данные по алгоритму упорядочения Юникода с использованием таблицы элементов упорядочения Юникода по умолчанию. Оно доступно во всех кодировках. Для использования данного правила требуется поддержка ICU, а поведение может измениться при сборке PostgreSQL с другой версией ICU. (Это правило имеет такое же поведение, как локаль корневого уровня ICU; см. und-x-icu (для «неопределенный»).)

ucs_basic

: Это стандартное правило сортировки SQL сортирует данные по значениям кодовых точек Юникода вместо естественного порядка языка и обрабатывает только буквы ASCII от «A» до «Z» как буквы. Поведение эффективно и стабильно для всех версий. Доступно только для кодировки UTF8. (Это правило имеет такое же поведение, как спецификация локализации libc C в кодировке UTF8.)

pg_c_utf8

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

C (эквивалентно POSIX)

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

default

: Правило сортировки default выбирает локаль, указанную при создании базы данных.

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

Предопределенные правила сортировки

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

Чтобы просмотреть доступные в данный момент локали, используйте запрос SELECT * FROM pg_collation, или команду \dOS+ в psql.

Правила сортировки libc

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

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

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

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

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

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

Правила сортировки ICU

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

Вот несколько примеров возможных созданных правил сортировки:

de-x-icu

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

de-AT-x-icu

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

(Также существуют, скажем, de-DE-x-icu или de-CH-x-icu, но на текущий момент они эквивалентны de-x-icu.)

und-x-icu (для «неопределенный»)

: Корневое правило сортировки ICU. Используйте его для получения разумного порядка сортировки, независимого от языка.

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

Создание новых объектов правил сортировки

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

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

Схемы упорядочивания libc

Новые схемы упорядочивания libc можно создать следующим образом:

CREATE COLLATION german (provider = libc, locale = 'de_DE');

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

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

Схемы упорядочивания ICU

Схемы упорядочивания ICU можно создать следующим образом:

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

Локали ICU задаются в виде метки языка стандарта BCP 47 Language Tag, но они также могут принимать большинство названий локалей стиля libc. При возможности названия локалей стиля libc преобразуются в языковые теги.

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

Копирование схем упорядочивания

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

CREATE COLLATION german FROM "de_DE";
CREATE COLLATION french FROM "fr-x-icu";

Недетерминированные схемы упорядочивания

Схема упорядочивания является либо детерминированной, либо недетерминированной. Детерминированная схема использует детерминированное сравнение, что означает, что она считает строки равными только тогда, когда они состоят из одной и той же последовательности байтов. Недетерминированное сравнение может определять равенство строк даже в том случае, если они состоят из разных байтовых последовательностей. Типичные ситуации включают нечувствительное к регистру сравнение, нечувствительное к акцентам сравнение, а также сравнение строк в различных нормальных формах Юникода. Реализация таких нечувствительных сравнений зависит от поставщика схемы упорядочивания; флаг детерминизма определяет лишь то, должны ли совпадения разбиваться путем побайтного сравнения. Дополнительную информацию по терминологии см. также в стандарте Юникод Технический стандарт 10.

Чтобы создать недетерминированную схему упорядочивания, задайте свойство deterministic = false равным CREATE COLLATION, например:

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

Этот пример использовал бы стандартные правила упорядочивания Юникода недетерминированным способом. В частности, это позволило бы правильно сравнивать строки в различных нормализованных формах. Более интересные примеры используют описанные выше средства настройки 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);

Все стандартные и предопределенные схемы упорядочивания являются детерминированными, все пользовательские схемы упорядочивания по умолчанию детерминированы. Хотя недетерминированные схемы обеспечивают более ««правильное» поведение, особенно учитывая полную мощь Юникода и его многочисленные особые случаи, у них также есть некоторые недостатки. Прежде всего, их использование приводит к снижению производительности. Обратите внимание, в частности, что дерево B не может использовать дедупликацию с индексами, использующими недетерминированную схему упорядочивания. Кроме того, некоторые операции невозможны с недетерминированными схемами, такими как операции сопоставления шаблонов. Поэтому их следует использовать только в тех случаях, когда они явно необходимы.

Совет

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

Пользовательские схемы упорядочивания ICU

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

-- ignore differences in accents and case
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

-- upper case letters sort before lower case.
CREATE COLLATION upper_first (provider = icu, locale = 'und-u-kf-upper');
SELECT 'B' < 'b' COLLATE upper_first; -- true

-- treat digits numerically and ignore punctuation
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

Многие доступные параметры описаны в разделе Настройки сортировки для локализации ICU или смотрите раздел Внешние ссылки для ICU для получения дополнительной информации.

Уровни сравнения ICU

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

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

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

Уровень	Описание	'f' = 'f'	'ab' = U&'a\2063b'	'x-y' = 'x_y'	'g' = 'G'	'n' = 'ñ'	'y' = 'z'
level1	Базовый символ	true	true	true	true	true	false
level2	Акценты	true	true	true	true	false	false
level3	Регистр/Варианты	true	true	true	false	false	false
level4	Пунктуация (a)	true	true	false	false	false	false
identic	Все	true	false	false	false	false	false

(a) только с ka-shifted, см. таблицу ниже.

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

Примеры уровней сортировки

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');

-- invisible separator ignored at all levels except identic
SELECT 'ab' = U&'a\2063b' COLLATE level4; -- true
SELECT 'ab' = U&'a\2063b' COLLATE identic; -- false

-- punctuation ignored at level3 but not at level 4
SELECT 'x-y' = 'x_y' COLLATE level3; -- true
SELECT 'x-y' = 'x_y' COLLATE level4; -- false

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

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

Настройки сортировки ICU:

Ключ	Значения	По умолчанию	Описание
co	emoji, phonebk, standard, ...	standard	Тип сортировки
ka	noignore, shifted	noignore	Если установлено значение shifted, некоторые символы (например, знаки препинания или пробелы) игнорируются при сравнении. Ключ ks должен быть установлен на уровень level3 или ниже, чтобы это сработало. Установите ключ kv, чтобы контролировать, какие классы символов игнорируются
kb	true, false	false	Обратное сравнение для различий второго уровня. Например, локаль und-u-kb сортирует 'àe' перед 'aé'
kc	true, false	false	Разделяет регистр символов на уровень «2.5», который находится между акцентами и другими особенностями уровня 3. Если установлено значение true и параметр ks установлен в level1, акценты будут игнорироваться, но регистр будет учитываться
kf	upper, lower, false	false	Если установлено значение upper, заглавные буквы сортируются перед строчными буквами. Если установлено значение lower, строчные буквы сортируются перед заглавными. Если установлено значение false, порядок сортировки зависит от правил локали
kn	true, false	false	Если установлено значение true, числа внутри строки обрабатываются как одно числовое значение, а не последовательность цифр. Например, 'id-45' сортируется перед 'id-123'
kk	true, false	false	Включает полную нормализацию; может повлиять на производительность. Базовая нормализация выполняется даже при установке значения false. Локали для языков, требующих полной нормализации, обычно включают ее по умолчанию. Полная нормализация важна в некоторых случаях, например, когда несколько акцентов применяются к одному символу. Например, последовательности кодовых точек U&'\0065\0323\0302' и U&'\0065\0302\0323' представляют собой букву e с циркумфлексом и точкой снизу, примененными в разном порядке. При включенной полной нормализации эти последовательности кодовых точек считаются равными, иначе они неравны.
kr	space, punct, symbol, currency, digit, script-id		Задается одним или несколькими допустимыми значениями или любым идентификатором языка BCP 47 script-id, например, latn («латиница») или grek («греческий»). Несколько значений разделяются символом -. Перезадает порядок классов символов; символы, принадлежащие классу, указанному ранее в списке, сортируются до символов, принадлежащих классу, указанному позже в списке. Например, значение digit-currency-space (в составе языкового тега вроде und-u-kr-digit-currency-space) сортирует знаки препинания перед цифрами и пробелами
ks	level1, level2, level3, level4, identic	level3	Чувствительность (или «степень») при определении равенства, где level1 наименее чувствителен к различиям, а identic наиболее чувствителен к различиям
kv	space, punct, symbol, currency	punct	Классы символов, игнорируемые во время сравнения на уровне 3. Установка более позднего значения включает предыдущие значения, например, symbol также включает punct и space среди символов, подлежащих игнорированию. Ключевая пара ka должна быть установлена в shifted, а ключевая пара ks — в level3 или ниже, чтобы это сработало

Значения по умолчанию могут зависеть от локали. Приведенная выше таблица не претендует на полноту. Дополнительные сведения см. в разделе «Внешние ссылки для ICU».

Примечание

Для многих настроек сопоставления необходимо создать сопоставление со значением deterministic, установленным в false, чтобы настройка имела желаемый эффект (см. раздел «Нестабильные правила упорядочивания»). Кроме того, некоторые настройки вступают в силу только тогда, когда ключ ka установлен в shifted.

Примеры настроек сопоставления

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 latinlast (provider = icu, locale = 'en-u-kr-grek-latn');

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

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

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

CREATE COLLATION special (provider = icu, locale = 'en-u-kf-upper-kr-grek-latn');

: Объединяет оба вышеуказанных варианта.

Правила адаптации 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

Внешние ссылки для ICU

Данный раздел («Пользовательские сопоставления ICU») представляет собой лишь краткий обзор поведения ICU и языковых меток. Для получения технических подробностей, дополнительных опций и нового функционала обратитесь к следующим документам:

• Технический стандарт Unicode № 35
• BCP 47
• Репозиторий CLDR
• https://unicode-org.github.io/icu/userguide/locale/
• https://unicode-org.github.io/icu/userguide/collation/