PostgreSQLLa base de données la plus sophistiquée au monde.

21. Localisation

Ce chapitre décrit les fonctionnalités disponibles pour la localisation du point de vue de l'administrateur. PostgreSQL™ supporte la localisation en utilisant deux approches :

  • Utiliser les fonctionnalités de locale du système d'exploitation pour donner un ordonnancement de tri, formatage de chiffre, des messages traduits et autres aspects spécifiques à la locale.

  • Donner un certain nombre de jeu de caractères différents définis dans le serveur PostgreSQL™, y compris des jeux de caractères multi-bit pour permettre de stocker du texte dans toutes sortes de langues et offrir la traduction de jeu de caractère entre serveur et client.

21.1. Support de locale

Le support de locale fait référence à une application respectant les préférences culturelles en ce qui concerne les alphabets, le tri, le format des nombres, etc. PostgreSQL™ utilise les possibilités du standard ISO C et de la locale POSIX fourni par le système d'exploitation serveur. Pour plus d'informations, consultez la documentation de votre serveur.

21.1.1. Aperçu

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 :

LC_COLLATE Ordre de tri des chaînes de caractères
LC_CTYPE Classification de caractères (Qu'est-ce qu'une lettre ? La majuscule équivalente ?)
LC_MESSAGES Langage des messages
LC_MONETARY Formatage des montants de monnaie
LC_NUMERIC Formatage des nombres
LC_TIME Formatage des dates et heures

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.

[Note]

Note

Lorsqu'on parle d'hériter la locale de l'environnement d'exécution, ceci veut dire la chose suivante sur la plupart des systèmes d'exploitation : pour une catégorie de locale donnée, disons l'ordonnancement, les variables d'environnement suivantes sont consultées dans cet ordre jusqu'à ce qu'on en trouve une de fixée : LC_ALL, LC_COLLATE (la variable correspondante à la catégorie respective), LANG. Si aucune de ces variables n'est fixée, alors on utilise la locale par défaut de C.

Certaines bibliothèques de localisation regardent aussi la variable d'environnement LANGUAGE qui surcharge tout autre paramètre pour le besoin de fixer la langue des messages. Si vous doutez, lisez la documentation de votre système d'exploitation, en particulier la documentation à propos de gettext, pour plus d'information.

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.

21.1.2. Comportement

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

  • Ordre de tri dans les requêtes utilisant ORDER BY sur des données de type texte

  • La possibilité d'utiliser des index avec les clauses LIKE

  • Les fonctions upper, lower et initcap

  • La famille de fonctions to_char

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.

21.1.3. Problèmes

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.