Le support de locale est automatiquement initialisé lorsqu'un cluster de base de données est créé avec initdb. initdb va initialiser le cluster avec la valeur de locale de son environnement d'exécution par défaut. Donc, si votre système est déjà paramétré pour utiliser la locale que vous voulez dans votre cluster, vous n'avez rien d'autre à faire. Si vous voulez utiliser une locale différente (ou si vous n'êtes pas sûr de la locale qu'utilise votre système), vous pouvez dire à initdb exactement quel locale utiliser en spécifiant l'option --locale. Par exemple :

initdb --locale=sv_SE

Cette exemple met la locale en suédois (sv) tel que parlé en Suède (SE). D'autres possibilités pourraient être en_US (l'anglais américain) et fr_CA (français canadien). Si plus d'un jeu de caractères peuvent être utiles pour une locale, alors la spécification ressemble à ceci : cs_CZ.ISO8859-2. Quels locales sont disponibles sous quels noms dépend de l'éditeur de votre système d'exploitation et de ce qui est installé (sur la plupart des systèmes, la commande locale -a fournira une liste de locales disponibles).

De façon occasionnelle, il est utile de mélanger les règles de plusieurs locales, i.e. utiliser les règles de tri anglais mais des messages en espagnol. Pour permettre ceci, des sous-catégories de locales existent qui ne contrôlent qu'un certain aspect des règles de localisation :

Les noms des catégories se traduisent en noms d'options initdb pour surcharger le choix de locale pour une catégorie donnée. Par exemple, pour mettre la locale en français canadien tout en utilisant les règles américaines pour le formatage de monnaie, utilisez initdb --locale=fr_CA --lc-monetary=en_US.

Pour obtenir que le système se comporte comme s'il n'avait pas de support de locale, on utilise les locales spéciales C ou POSIX.

La nature de ces catégories de locales est que leur valeur doit être fixe pour la durée de vie d'un cluster de base de données. C'est-à-dire qu'une fois initdb lancée, on ne peut plus les changer. LC_COLLATE et LC_CTYPE sont ces catégories. Ils affectent l'ordre de tri des index, donc ils doivent rester fixes ou les index sur les colonnes de texte deviendront corrompus. PostgreSQL™ applique ceci en enregistrant les valeurs de LC_COLLATE et LC_CTYPE qui sont vus par initdb. Le serveur adopte automatiquement ces deux valeurs lorsqu'il est exécuté.

Les autres catégories de locale peuvent être changées comme désiré lorsque le serveur est lancé en fixant les variables d'environnement qui ont le même nom que les catégories de locale (voir la Section 17.10.2, « Locale et formatage » pour plus de détails). Les valeurs par défaut choisies par initdb sont en fait seulement écrites dans le fichier de configuration postgresql.conf pour servir de valeur par défaut quand le serveur est lancé. Si vous effacez ces déclarations de postgresql.conf, alors le serveur héritera des paramètres de son environnement d'exécution.

Notez que le comportement de locale du serveur est déterminé par les variables d'environnement vues par le serveur, pas l'environnement d'un client quelconque. Alors, faites attention de configurer les bons paramètres de locale avant de lancer le serveur. Une conséquence de ceci est que, si le client et le serveur ont des locales différentes, les messages apparaîtront dans des langues différentes suivant d'où ils viennent.

Pour permettre la traduction des messages dans la langue préférée de l'utilisateur, NLS doit être activé pendant la compilation. Ce choix est indépendant d'autre support de locale.

Le paramétrage de la locale influence les fonctionnalités SQL suivantes :

L'inconvénient d'utiliser le support de locale autres que C ou POSIX dans PostgreSQL™ est son impact sur les performances. Il ralentit la gestion des caractères et empêche l'utilisation des index ordinaires par LIKE. Pour cette raison, il est recommandé de n'utiliser les locales que lorsque cela est réellement nécessaire.

Comme contournement pour que PostgreSQL™ puisse utiliser des index avec les clauses LIKE et une locale autre que C, plusieurs classes d'opérateurs personnalisés existent. Elles permettent la création d'un index qui fait une comparaison stricte, caractère par caractère, ignorant les règles de comparaison des locales. Référez-vous à la Section 11.8, « Classes d'opérateurs » pour plus d'informations.

Si le support de locale ne fonctionne pas malgré l'explication ci-dessus, vérifiez que le support de locale de votre système d'exploitation est correctement configuré. Pour vérifier quelles locales sont installées sur votre système, vous pouvez utiliser la commande locale -a si votre système d'exploitation la fournit.

Vérifiez que PostgreSQL™ utilise vraiment la locale que vous supposez. Les paramètres LC_COLLATE et LC_CTYPE sont déterminés lors de initdb et ne peuvent pas être modifiés sans répéter initdb. D'autres paramètres de locale, y compris LC_MESSAGES et LC_MONETARY, sont déterminés initialement par l'environnement dans lequel le serveur est lancé mais peut être modifié en cours. Vous pouvez vérifier les paramétrages de la locale active en utilisant la commande SHOW.

Le répertoire src/test/locale dans la distribution du source contient une série de tests pour le support de locale dans PostgreSQL™.

Les applications clientes qui gèrent les erreurs côté serveur en analysant le texte du message d'erreur auront, bien sûr, des problèmes lorsque les messages sont dans une langue différente. Les auteurs de telles applications sont invités à utiliser le schéma de code d'erreur à la place.

Maintenir des catalogues de traductions de messages requiert les efforts permanents de beaucoup de volontaires qui souhaitent voir PostgreSQL™ bien interpréter leur langue préférée. Si des messages dans votre langue ne sont pas disponibles ou pas complètement traduits, votre aide serait très appréciée. Si vous voulez aider, consultez le Chapitre 45, Support natif des langues ou écrivez à la liste de diffusion des développeurs.