Cette fonctionnalité permet de définir par colonne, ou pour chaque requête,
la collation utilisée pour déterminer l'ordre de tri et le classement des
caractères.
Elle permet de lever la restriction sur les paramètres
LC_COLLATE
et LC_CTYPE
d'une base de
données, qui ne pouvaient pas être modifiés après sa création.
Conceptuellement, toute expression d'un type de donnée supportant les
collations a une collation. (Les types de données intégrés supportant les
collations sont text
, varchar
, et
char
. Les types de données définis par l'utilisateur peuvent
aussi être marqués comme supportant les collations. Bien entendu, un
domaine défini sur un type
de données supportant les collations les supporte aussi.) Si l'expression
est une référence de colonne, la collation de l'expression est déterminée
par la collation de la colonne. Si l'expression est une constante, la
collation sera celle par défaut du type de la constante. La collation d'une
expression plus complexe est déterminée à partir des différentes collations
de ses entrées, comme cela est décrit ci-dessous.
Une expression peut prendre la collation par défaut, « default », c'est-à-dire la collation définie au niveau de la base de données. Il est possible que la collation d'une expression soit indéterminée. Dans un tel cas, les tris et les autres opérations ayant besoin de connaître la collation vont échouer.
Lorsque la base de données doit réaliser un tri ou classement de caractères,
elle utilise la collation de l'expression entrée. Ce cas se présentera, par
exemple, avec des clauses ORDER BY
, ou des appels à des
fonctions ou opérateurs tels que <
. La collation à
appliquer à une clause ORDER BY
est simplement la
collation de la clé de tri. La collation à appliquer pour l'appel à une
fonction ou à un opérateur est dérivée des arguments, comme décrit plus bas.
En plus de s'appliquer aux opérateurs de comparaison, les collations sont
également prises en compte par les fonctions qui convertissent entre
minuscules et majuscules, comme lower
,
upper
et initcap
, par les
opérateurs de correspondance de motifs, et par to_char
et les fonctions affiliées.
Pour un appel à une fonction ou un opérateur, la collation dérivée des collations des arguments est utilisée à l'exécution de l'opération. Si le type du résultat de la fonction ou de l'opérateur supporte les collations, alors cette collation est utilisée dès l'analyse en tant que la collation de la fonction ou de l'opérateur, au cas où une expression voisine nécessiterait de la connaître.
Le calcul de la collation d'une expression est
réalisé implicitement ou explicitement. Cette distinction affecte la façon
dont les collations sont combinées entre elles quand plusieurs collations
différentes apparaissent dans une expression. Une dérivation explicite
utilise la clause COLLATE
; dans tous les autres
cas, la dérivation de collation est implicite. Les règles suivantes
s'appliquent lorsque plusieurs collations doivent être utilisée en même
temps, par exemple dans un appel à une fonction :
Si une expression en entrée porte une dérivation de collation explicite, alors toutes les collations explicitement dérivées des autres expressions en entrée doivent être identiques, sinon une erreur est levée. Si une collation explicitement dérivée est présente, elle est le résultat de la combinaison des collations.
Dans les autres cas, toutes les expressions en entrée doivent avoir la même collation, qu'elle soit implicitement dérivée, ou celle par défaut. Si est présente une collation autre que celle par défaut, alors elle est aussi le résultat de la combinaison des collations. Sinon, le résultat correspond à la collation par défaut.
S'il existe, parmi les expressions en entrée, des collations implicites, qui ne sont pas celles par défaut, et qui entrent en conflit, alors la combinaison ne peut aboutir qu'à une collation indéterminée. Ce n'est pas une erreur, sauf si la fonction appelée requiert une application de la collation. Dans ce cas, une erreur est renvoyée lors de l'exécution.
Par exemple, considérez la table définie de la façon suivante:
CREATE TABLE test1 ( a text COLLATE "de_DE", b text COLLATE "es_ES", ... );
Ensuite, dans la requête
SELECT a < 'foo' FROM test1;
la comparaison <
est réalisée selon
les règles de la locale de_DE
, car l'expression
combine une collation dérivée implicitement avec la collation par défaut.
Mais, dans la requête
SELECT a < ('foo' COLLATE "fr_FR") FROM test1;
la comparaison est effectuée en utilisant les règles de la locale fr_FR
,
parce que l'utilisation explicite de cette locale prévaut sur la locale
implicite.
De plus, avec la requête
SELECT a < b FROM test1;
l'analyseur ne dispose pas des éléments pour déterminer quelle collation
employer, car les collations des colonnes a
et b
sont différentes. Comme l'opérateur <
a besoin de savoir
la locale à utiliser, on obtiendra une erreur. Elle peut être résolue
en attachant une déclaration de collation explicite à l'une ou l'autre des expressions
d'entrées, soit :
SELECT a < b COLLATE "de_DE" FROM test1;
ou de manière équivalente
SELECT a COLLATE "de_DE" < b FROM test1;
Toutefois, dans ce cas suivant, structurellement similaire,
SELECT a || b FROM test1;
il n'y aura pas d'erreur, car l'opérateur ||
ne tient
pas compte des collations : son résultat sera le même quelle qu'elle soit.
La collation assignée à une fonction ou à une combinaison d'un opérateur avec ses expressions d'entrées s'applique également au résultat de la fonction ou de l'opérateur, si le résultat est d'un type supportant les collations. Ainsi, dans la requête
SELECT * FROM test1 ORDER BY a || 'foo';
le tri sera réalisé en fonction des règles de la locale de_DE
.
Mais cette requête :
SELECT * FROM test1 ORDER BY a || b;
retournera une erreur car, bien que l'opérateur ||
ne tienne pas
compte des collations de ses expressions, la clause ORDER BY
, elle, en tient
compte. Comme précédemment, ce conflit peut être résolu par l'emploi d'une
déclaration explicite de la collation :
SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
Une collation est un objet du catalogue SQL qui associe un nom SQL à une
locale fournie par les bibliothèques installées sur le système. Une
définition de collation a un fournisseur, qui
spécifie quelle bibliothèque fournit les données locales. L'un des
fournisseurs standards est libc
, qui utilise les locales
fournies par la bibliothèque C du système. Ce sont les locales utilisées par
la plupart des outils du système. Un autre fournisseur est
icu
, qui utilise la bibliothèque externe
ICU. Les locales ICU ne peuvent
être utilisées que si le support d'ICU a été configuré lors de la
compilation de PostgreSQL.
Un objet de type collation fourni par la libc
pointe sur
une combinaison de paramètres LC_COLLATE
et
LC_CTYPE
, comme acceptés par l'appel système
setlocale()
.
(Comme le nom le suggère, le principal objectif d'une collation est de
positionner LC_COLLATE
, qui contrôle l'ordre de tri.
Dans la pratique, il est très rarement nécessaire de définir un
paramètre LC_CTYPE
différent de
LC_COLLATE
. Il est donc plus facile de
regrouper ces deux paramètres dans un même concept, que de créer
une infrastructure différente simplement pour pouvoir positionner
LC_CTYPE
pour chaque expression.) De la même façon, une
collation libc
est liée à un encodage de jeu de caractère (voir Section 24.3).
Le même nom de collation peut exister pour différents encodages.
Un objet de type collation fourni par icu
pointe sur un collateur nommé
fourni par la bibliothèque ICU. ICU ne permet pas de séparer
« collate » et « ctype », ils sont donc
toujours les mêmes. De même, les collations ICU sont indépendantes de
l'encodage ; il n'y a donc toujours qu'une seule collation ICU pour un nom donné dans une
base de données.
Les collations nommées default
, C
, et POSIX
sont disponibles sur toutes les plateformes. Des collations complémentaires peuvent
être disponibles, ou non, en fonction du support au niveau du système d'exploitation.
La collation default
utilise les valeurs de
LC_COLLATE
et LC_CTYPE
définies à la création de la base de données. Les collations C
et
POSIX
spécifient toutes deux le comportement « C traditionnel »,
dans lequel seuls les caractères ASCII de « A
» à
« Z
» sont considérés comme des lettres, et les tris sont
ordonnés strictement par valeur de l'octet du code caractère.
Les locales C
et POSIX
peuvent se
comporter différemment selon l'encodage des bases de données.
En plus, deux noms de collation du standard SQL sont disponibles :
unicode
Cette collation trie en utilisant l'algorithme de collation Unicode avec
la table d'éléments de collation Unicode par défaut. Il est disponible
dans tous les encodages. Le support ICU est requis pour cette collation.
(Cette collation a le même comportement que la locale racine ICU ; voir
und-x-icu
(pour « undefined »).)
ucs_basic
Cette collation trie par point code Unicode. Elle est seulement
disponible pour l'encodage UTF8
. (Cette collation
a le même comportement que la spécification C
de
la locale libc dans l'encodage UTF8
).
Si le système d'exploitation permet de supporter plusieurs
locales dans un même programme (fonction newlocale
et fonctions conjointes),
ou si le support d'ICU est configuré, alors
initdb
peuplera le catalogue système pg_collation
avec toutes les locales trouvées sur le système d'exploitation
lors de l'initialisation de l'instance.
Pour inspecter les locales actuellement disponibles, utilisez la requête SELECT
* FROM pg_collation
, ou la commande \dOS+
dans psql.
Par exemple, le système
d'exploitation peut fournir une locale appelée de_DE.utf8
.
initdb
créera alors une collation nommée
de_DE.utf8
pour le jeu de caractère UTF8
,
pour laquelle LC_COLLATE
et LC_CTYPE
seront
positionnés à de_DE.utf8
.
Il créera aussi une collation avec un nom amputé de l'étiquette .utf8
.
Ainsi, vous pourrez utiliser cette collation sous le nom de_DE
,
plus facile à écrire, et moins dépendant du jeu
de caractères. Néanmoins, notez que l'ensemble initial des noms de collation
initdb
est dépendant de la plateforme.
Le jeu de collation par défaut fourni par libc
pointe
directement vers les locales installées sur le système, qui peuvent être
listées avec la commande locale -a
. Dans le cas
où l'on a besoin d'une collation libc
avec des valeurs
LC_COLLATE
et LC_CTYPE
différentes, ou si de nouvelles
locales sont installées sur le système après l'initialisation de la base de données,
une nouvelle collation peut être créée par
la commande CREATE COLLATION. On peut aussi importer
en masse de nouvelles locales du système d'exploitation avec
la fonction pg_import_system_collations()
.
Dans une même base de données, seules les collations qui utilisent le
jeu de caractères de la base de données sont prises en compte. Les autres
entrées de pg_collation
sont ignorées. Ainsi,
une collation au nom tronqué, comme de_DE
,
peut être considérée unique au sein d'une base,
bien qu'elle ne le soit pas globalement.
L'utilisation de collations au nom tronqué est d'ailleurs
recommandée : ce sera une chose de moins à changer si vous avez besoin
de changer le jeu de caractères de la base de données. Notez toutefois que
les collations default
, C
, et
POSIX
peuvent être utilisées sans se soucier de
l'encodage de la base de données.
PostgreSQL considère les collations comme des objets distincts et incompatibles entre eux, même si elles possèdent des propriétés identiques. Ainsi, par exemple,
SELECT a COLLATE "C" < b COLLATE "POSIX" FROM test1;
va afficher une erreur alors que les collations C
et
POSIX
possèdent des propriétés strictement identiques. Il n'est
donc pas recommandé de mélanger des collations dont le nom est complet
avec des collations dont le nom l'est pas.
Avec ICU, il n'est pas raisonnable d'énumérer tous les noms de locales
possibles. ICU utilise un système de nommage particulier pour les
locales, mais il y a plus de façons de nommer une locale qu'il n'y en a
réellement de distinctes. initdb
utilise les API d'ICU pour extraire un jeu de locales distinctes, afin de
peupler le jeu initial de collations. Les collations fournies par ICU sont
créées dans l'environnement SQL avec des noms suivant le format d'étiquettes
de langues BCP 47, plus une extension d'« utilisation privée »
-x-icu
, ajoutée pour les distinguer des locales de libc.
Voici quelques exemples de collations pouvant être créées :
de-x-icu
#Collation allemande, variante par défaut
de-AT-x-icu
#Collation allemande pour l'Autriche, variante par défaut
(Il y a aussi, par exemple, de-DE-x-icu
ou
de-CH-x-icu
mais, au moment de l'écriture de ces lignes,
elles sont équivalentes à de-x-icu
.)
und-x-icu
(pour « undefined ») #Collation « racine » ICU. Utilisez ceci pour avoir un ordre de tri raisonnable et linguistiquement agnostique.
Certains encodages (les moins fréquemment utilisés) ne sont pas
supportés par ICU. Si c'est le cas pour l'encodage de la base de données,
les enregistrements de collations ICU dans pg_collation
sont ignorés. Tenter d'en utiliser un renverra une erreur du type
« collation "de-x-icu" for encoding "WIN874" does not exist ».
Si les collations standards et prédéfinies ne sont pas suffisantes, les utilisateurs peuvent créer leur propres objets de collation en utilisant la commande SQL CREATE COLLATION.
Les collations standards et prédéfinies sont dans le schéma
pg_catalog
, comme tous les objets prédéfinis. Les
collations définies par les utilisateurs doivent être créées dans des
schémas utilisateurs. Ceci assure qu'elles seront sauvegardées par
pg_dump
.
Les nouvelles collations libc peuvent être créées ainsi :
CREATE COLLATION german (provider = libc, locale = 'de_DE');
Les valeurs exactes de la clause locale
acceptées par cette commande dépendent du système
d'exploitation. Sur les systèmes Unix, la commande locale
-a
affichera une liste.
Comme les collations libc prédéfinies incluent déjà toutes les collations
définies dans le système d'exploitation au moment de l'initialisation de
l'instance, il n'est pas souvent nécessaire d'en créer de nouvelles.
Des raisons possibles sont l'utilisation d'un autre système
de nommage (auquel cas, voir aussi Section 24.2.2.3.3), ou
une mise à jour du système d'exploitation pour fournir les définitions
des nouvelles locales (auquel cas, voir aussi pg_import_system_collations()
).
Les collations ICU peuvent être créées comme :
CREATE COLLATION german (provider = icu, locale = 'de-DE');
Les locales ICU sont spécifiées comme une étiquette de langage BCP 47, mais peuvent aussi accepter la plupart des noms de locales en style libc. Si possible, les noms de locales en style libc sont transformés en étiquettes de langage.
Les nouvelles collations ICU peuvent personnaliser le comportement de collation de manière étendue en incluant des attributs de collation dans les étiquettes de langage. Voir Section 24.2.3 pour les détails et exemples.
La commande CREATE COLLATION peut également être utilisée pour créer une nouvelle collation depuis une collation existante, ce qui peut être utile pour utiliser une collation indépendante du système dans les applications, de créer des noms compatibles, ou d'utiliser une collation fournie par ICU avec un nom plus lisible. Par exemple :
CREATE COLLATION german FROM "de_DE"; CREATE COLLATION french FROM "fr-x-icu";
Une collation est soit déterministe, soit non déterministe. Une collation déterministe utilise des comparaisons déterministes, ce qui signifie qu'elle considère les chaînes de caractères comme égales seulement si elles sont constituées des mêmes séquences d'octets. Les comparaisons non déterministes peuvent considérer des chaînes comme égales même si elles sont constituées d'octets différents. Les cas d'usage typiques comprennent des comparaisons insensibles à la casse, ou insensibles aux accents, de même que la comparaison de chaînes dans différentes formes normales Unicode. C'est au fournisseur de collation d'implémenter de telles comparaisons insensibles ; le drapeau donnant la collation comme déterministe n'indique que si les chaînes égales doivent être départagées ou non par une comparaison au niveau de l'octet. Voir aussi Unicode Technical Standard 10 pour plus d'information sur la terminologie.
Pour créer une collation non déterministe, spécifiez la propriété
deterministic = false
à CREATE
COLLATION
, par exemple:
CREATE COLLATION ndcoll (provider = icu, locale = 'und', deterministic = false);
Cet exemple utiliserait la collation Unicode standard d'une manière non déterministe. En particulier, elle permettrait à des chaînes exprimées dans différentes formes normales d'être comparées correctement. D'autres exemples plus intéressants utilisent les facultés de personnalisation d'ICU expliquées ci-dessus. Par exemple :
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);
Toutes les collations standards et prédéfinies sont déterministes, et toutes les collations définies par les utilisateurs sont déterministes par défaut. Bien que les collations non déterministes aient un comportement plus « correct », particulièrement considérant la puissance d'Unicode et ses nombreux cas spécifiques, elles ont aussi quelques inconvénients. D'abord, leur utilisation génère une pénalité de performance. Il est à noter en particulier qu'un B-tree ne peut pas utiliser la déduplication dans les index utilisant une collation non déterministe. Par ailleurs, certaines opérations ne sont pas possibles avec des collations non déterministes, comme la recherche par motif. Par conséquent, elles ne devraient être utilisées que dans les cas où elles sont spécifiquement désirables.
Pour gérer du texte sous différentes formes de normalisation Unicode, il
est possible d'utiliser les fonctions ou expressions
normalize
et is normalized
pour
prétraiter ou contrôler les chaînes de caractères, au lieu d'utiliser des
collations non déterministes. Il y a des avantages et inconvénients différents
à chaque approche.
ICU permet un contrôle étendu sur le comportement des collations en définissant de nouvelles collations avec des paramètres de collation sous forme de partie d'étiquettes de langage. Par exemple :
-- Ignore les différences d'accents et de casse. CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1'); SELECT 'Å' = 'A' COLLATE ignore_accent_case; -- vrai SELECT 'z' = 'Z' COLLATE ignore_accent_case; -- vrai -- Les lettres en majuscule sont triées avant celles en minuscule. CREATE COLLATION upper_first (provider = icu, locale = 'und-u-kf-upper'); SELECT 'B' < 'b' COLLATE upper_first; -- vrai -- Traite les chiffres en nombre et ignore la ponctuation CREATE COLLATION num_ignore_punct (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-kn'); SELECT 'id-45' < 'id-123' COLLATE num_ignore_punct; -- vrai SELECT 'w;x*y-z' = 'wxyz' COLLATE num_ignore_punct; -- vrai
Les nombreuses options disponibles sont décrites dans Section 24.2.3.2, ou voir Section 24.2.3.5 pour plus de détails.
La comparaison de deux chaînes (collation) en ICU est déterminée par un processus multi-niveaux, où les fonctionnalités textuelles sont regroupées en niveaux. Le traitement de chaque niveau est contrôlé par les paramètres de collation. Les plus hauts niveaux correspondent aux fonctionnalités textuelles les plus fines.
Tableau 24.1 indique quelles différences
de fonctionnalité textuelle sont considérées
significatives quand l'égalité est déterminée au niveau donné.
Le caractère unicode U+2063
est un séparateur invisible, et
comme indiqué dans la table, est ignoré pour tous les niveaux de comparaison inférieur à
identic
.
Tableau 24.1. Niveaux de collation ICU
Niveau | Description | 'f' = 'f' | 'ab' = U&'a\2063b' | 'x-y' = 'x_y' | 'g' = 'G' | 'n' = 'ñ' | 'y' = 'z' |
---|---|---|---|---|---|---|---|
Niveau 1 (level1) | Caractère de base | vrai | vrai | vrai | vrai | vrai | faux |
Niveau 2 (level2) | Accents | vrai | vrai | vrai | vrai | faux | faux |
Niveau 3 (level3) | Casse/Variants | vrai | vrai | vrai | faux | faux | faux |
Niveau 4 (level4) | Ponctuation | vrai | vrai | faux | faux | faux | faux |
identique (identic) | Tous | vrai | faux | faux | faux | faux | faux |
À chaque niveau, même en avec la normalisation complètement inactivée, la normalisation
de base est effectuée. Par exemple, 'á'
peut être composé
des points codes U&'\0061\0301'
ou du point code unique
U&'\00E1'
, et ces séquences seront considérées équivalentes
même au niveau identic
. Pour traiter toute
différence de représentation en point code comme distincte, utilisez une
collation créée avec deterministic
mis à vrai
.
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'); -- séparateur invisible ignoré à tous niveaux sauf identic SELECT 'ab' = U&'a\2063b' COLLATE level4; -- vrai SELECT 'ab' = U&'a\2063b' COLLATE identic; -- faux -- ponctuation ignorée à niveau 3 mais pas à niveau 4 SELECT 'x-y' = 'x_y' COLLATE level3; -- vrai SELECT 'x-y' = 'x_y' COLLATE level4; -- faux
Tableau 24.2 indique les paramètres de collation disponibles, qui peuvent être utilisés sous forme de partie d'étiquette de langage pour personnaliser une collation.
Tableau 24.2. Paramètres de collation ICU
Clés | Valeurs | Défaut | Description |
---|---|---|---|
co | emoji , phonebk , standard , ... | standard | Type de collation. Voir Section 24.2.3.5 pour les options supplémentaires et détails. |
ka | noignore , shifted | noignore |
Si affecté à shifted , fait que certains caractères
(i.e. ponctuation ou espace) sont ignorés dans les comparaisons.
La clé ks doit être mise à level3 ou
inférieure pour prendre effet. Affecter la clé kv pour
contrôler les classes de caractères à ignorer.
|
kb | true , false | false |
Comparaisons descendantes pour les différences du niveau 2.
Par exemple, la locale und-u-kb trie
'àe' avant 'aé' .
|
kc | true , false | false |
Sépare la casse en un niveau 2.5 qui tombe entre les accents et les autres fonctionnalités de niveau 3.
Si mis à |
kf |
upper , lower ,
false
| false |
Si mis à upper , la majuscule est triée avant la minuscule.
Si mis à lower , la minuscule est triée avant la majuscule.
Si mis à false , le tri dépend des règles de la locale.
|
kn | true , false | false |
Si mis à true , les nombres à l'intérieur d'une chaîne sont
traités comme une valeur numérique unique plutôt qu'une séquence de chiffres.
Par exemple, 'id-45' est trié avant 'id-123' .
|
kk | true , false | false |
Permet une normalisation complète ; peut affecter les performances.
La normalisation de base est effectuée quand ce paramètre vaut
La normalisation complète est importante dans certains cas, tel que
lorsque plusieurs accents sont appliqués sur un seul caractère.
Par exemple, les séquences de code point |
kr |
space , punct ,
symbol , currency ,
digit , script-id
|
Affectez à une ou plusieurs de ces valeurs valides, ou n'importe
quel
Redéfinit l'ordonnancement des classes de caractères ; les caractères
d'une classe placée plus tôt dans cette liste sont triés avant les caractères
d'une classe placée après dans la liste. Par exemple,
la valeur | |
ks | level1 , level2 , level3 , level4 , identic | level3 |
Sensibilité (ou force) quand il faut déterminer l'égalité, avec
level1 étant le moins sensible aux différences et
identic le plus sensible aux différences. Voir
Tableau 24.1 pour les détails.
|
kv |
space , punct ,
symbol , currency
| punct |
Classes de caractères ignorés durant la comparaison au niveau 3. Affecter
ce paramètre à une valeur postérieure inclut déjà les valeurs précédentes ;
i.e. symbol inclut aussi
punct et space dans les caractères à
ignorés. La clé ka doit être affecté à
shifted et la clé ks doit être
affectée à level3 ou moins pour faire effet.
|
Les défauts peuvent dépendre de la locale. La table ci-dessus n'a pas
vocation à être complète. Voir Section 24.2.3.5
pour des options supplémentaires et des détails.
Pour de nombreux paramètres de collation, vous devez créer la collation avec
deterministic
mis à false
pour que
les paramètres puissent avoir l'effet désiré (voir Section 24.2.2.4). En plus, certains paramètres
ne prennent effet que si la clé ka
est affectée à
shifted
(voir Tableau 24.2).
CREATE COLLATION "de-u-co-phonebk-x-icu" (provider = icu, locale = 'de-u-co-phonebk');
#Collation Allemande avec une collation de type agenda téléphonique
CREATE COLLATION "und-u-co-emoji-x-icu" (provider = icu, locale = 'und-u-co-emoji');
#Collation racine avec une collation de type Emoji, pour le standard technique Unicode #51
CREATE COLLATION latinlast (provider = icu, locale = 'en-u-kr-grek-latn');
#Trie des lettres grecques avant les latines. (Le défaut est Latin avant Grec.)
CREATE COLLATION upperfirst (provider = icu, locale = 'en-u-kf-upper');
#Trie les lettres en majuscule avant les lettres en minuscule. (Le défaut est les lettres en minuscule en premier.)
CREATE COLLATION special (provider = icu, locale = 'en-u-kf-upper-kr-grek-latn');
#Combine ensemble les deux options ci-dessus.
If the options provided by the collation settings shown above are not sufficient, the order of collation elements can be changed with tailoring rules, whose syntax is detailed at https://unicode-org.github.io/icu/userguide/collation/customization/.
This small example creates a collation based on the root locale with a tailoring rule:
CREATE COLLATION custom (provider = icu, locale = 'und', rules = '&V << w <<< W');
With this rule, the letter « W » is sorted after « V », but is treated as a secondary difference similar to an accent. Rules like this are contained in the locale definitions of some languages. (Of course, if a locale definition already contains the desired rules, then they don't need to be specified again explicitly.)
Here is a more complex example. The following statement sets up a
collation named ebcdic
with rules to sort US-ASCII
characters in the order of the EBCDIC encoding.
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
La section (Section 24.2.3) est seulement un bref aperçu des comportements ICU et des étiquettes de langage. Reférez vous aux documents suivants pour les détails techniques, options supplémentaires et nouveaux comportements :