Conceptuellement, toute expression d'un type de donnée qui est collatable a une collation. (Les types de données intégrés qui supportent une collation sont text, varchar, et char. Les types de données définies par l'utilisateur peuvent aussi être marquées comme supportant la collation, et bien entendu un domaine qui est défini sur un type de données supportant la collation est, lui aussi, collationnable.) Si l'expression est une colonne, la collation de l'expression est déterminée par la collation de la colonne. Si l'expression est une constante, la collation utilisée sera la collation par défaut du type de données 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 opérations de tri et les autres opérations qui ont besoin de connaître la collation vont échouer.

Lorsque la base de données doit réaliser un tri ou classement de caractères, alors elle utilisera la collation de l'expression en entrée. Ce cas se présentera, par exemple, si vous employez la clause ORDER BY et des appels à des fonctions ou des opérateurs tels que <. La collation qui s'applique à une clause ORDER BY est simplement la collation de la clé de tri. La collation qui s'applique pour l'appel à une fonction ou à un opérateur est dérivé 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 réalisent les conversions 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 est déterminée à partir de la collation des arguments qui sont passés à l'exécution de l'opération. Si une expression voisine nécessite de connaître la collation de la fonction ou de l'opérateur, et si le type de données du résultat de l'appel possède une collation alors cette collation est interprétée comme la collation de l'expression au moment de l'analyse.

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 lorsque plusieurs collations différentes sont utilisées dans une expression. La collation d'une expression peut être déterminée explicitement par l'emploi de la clause COLLATE; dans les autres cas, la collation est déterminée de manière 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, les règles suivantes s'appliquent:

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 en tenant compte des règles de la locale de_DE, parce que l'expression combine la collation calculé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 déterminée de manière 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 connaître quelle locale utiliser, une erreur sera générée. Cette erreur 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, pour cas structurellement similaire comme

SELECT a || b FROM test1;

ne retournera pas d'erreur car l'opérateur || ne tient pas compte des collations: son résultat sera le même quel que soit la collation.

La collation qui est assignée à une fonction ou à une combinaisons d'un opérateur avec ses expressions d'entrées s'appliquent également au résultat de la fonction ou de l'opérateur. Bien évidemment, cela s'applique que si la fonction de l'opérateur délivre un résultat dans un type de données auquel la collation peut s'appliquer. Ainsi, dans la requête

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

le tri sera réalisé en fonction de 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 en tient compte. Comme précédemment, ce conflit peut être résolue par l'emploi d'une déclaration explicite de collation:

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

Une collation est un objet du catalogue dont le nom au niveau SQL correspond à une locale du système d'exploitation. Et plus particulièrement, elle l'associe à une combinaison de LC_COLLATE et LC_CTYPE. (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. De cette façon, il est plus facile de regrouper ces deux paramètres dans un même concept plutôt que de créer une infrastructure différente simplement pour pouvoir positionner LC_CTYPE pour chaque requête.) De la même façon, une collation est liée à un jeu de caractère (voir Section 22.3, « Support des jeux de caractères »). Ainsi, plusieurs jeux de caractères peuvent utiliser une collation portant le même nom.

Les collations nommées default, C, et POSIX sont disponibles sur toutes les plateformes. Les collations complémentaires seront ou non disponibles en fonction de leur support au niveau du système d'exploitation. La collation default permet d'utiliser les valeurs de LC_COLLATE et LC_CTYPE telles qu'elles ont été définies à la création de la base de données. Les collations C et POSIX spécifie toute deux le comportement « traditionnel C », dans lequel seules les caractères ASCII de « A » à « Z » sont considérées comme des lettres, et les tris sont ordonnés strictement par valeur de l'octet du code caractère.

Si le système d'exploitation permet à un programme de supporter plusieurs locales (fonction newlocale et fonctions conjointes), alors initdb peuplera le catalogue système pg_collation en se basant sur toutes les locales qu'il trouve sur le système d'exploitation au moment de l'initialisation du cluster de bases de données. Par exemple, le système d'exploitation peut offrir 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 lequel LC_COLLATE et LC_CTYPE sont positionnés à de_DE.utf8. Il créera aussi une collation dont le nom sera amputé du tag .utf8. Ainsi, vous pouvez utiliser cette collation sous le nom de_DE, dont l'écriture est beaucoup plus facile et qui le rend moins dépendant du jeu de caractères.Néanmoins, notez que le nommage de chaque collation collectée par initdb est dépendant de la plateforme utilisée.

Si vous souhaitez utiliser une collation dont les valeurs LC_COLLATE et LC_CTYPE diffèrent, il vous faudra créer une nouvelle collation par le biais de la commande CREATE COLLATION(7). Cette commande peut également être utilisée pour créer une nouvelle collation à partir d'une collation existante, ce qui être utile pour utiliser dans vos applications des collations dont le nom est indépendant du système d'exploitation.

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 pris en compte. Les autres entrées de pg_collation sont ignorées. De cette façon, une collation dont le nom est tronqué, comme de_DE, sera considéré de manière unique au sein d'une même base de données, même si elle ne peut être considérée comme unique à un niveau plus global. L'utilisation de collations dont le nom est tronqué est d'ailleurs recommandé car vous n'aurez pas besoin de le modifier si vous décidez 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é sans se soucier du jeu de caractères 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 exemle,

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.