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 :

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 23.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.

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

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

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

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

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

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

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 23.2.3.2, ou voir Section 23.2.3.5 pour plus de détails.

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

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

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