Le support des locales est automatiquement déclenché lorsqu'un cluster de base de données est créé avec initdb. initdb initialise le cluster avec la valeur des locales de son environnement d'exécution par défaut. Si le système est déjà paramétré pour utiliser la locale souhaitée pour le cluster, il n'y a donc rien d'autre à faire. Si une locale différente est souhaitée (ou que celle utilisée par le serveur n'est pas connue avec certitude), il est possible d'indiquer à initdb la locale à utiliser à l'aide de l'option --locale. Par exemple :

initdb --locale=sv_SE

Cet exemple positionne la locale au suédois (sv) tel que parlé en Suède (SE). Parmi les autres possibilités, on peut envisager en_US (l'anglais américain) ou fr_CA (français canadien). Si plusieurs encodages s'avèrent utiles pour une même locale, alors l'indication peut ressembler à : cs_CZ.ISO8859-2. Les locales disponibles et leurs noms dépendent de l'éditeur du système d'exploitation et de ce qui est installé (sur la plupart des systèmes, la commande locale -a fournit la liste des locales disponibles).

Il est parfois utile de mélanger les règles de plusieurs locales, par exemple d'utiliser les règles de tri anglais avec des messages en espagnol. Pour cela, des sous-catégories de locales existent qui ne contrôlent qu'un aspect particulier 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 utiliser la locale français canadien avec des règles américaines pour le formatage monétaire, on utilise initdb --locale=fr_CA --lc-monetary=en_US.

Pour bénéficier d'un système qui se comporte comme s'il ne disposait pas du support des locales, on utilise les locales spéciales C ou POSIX.

La nature de certaines catégories de locales oblige à les fixer pour la durée de vie d'un cluster. C'est-à-dire qu'une fois qu'initdb à été lancé, elles ne peuvent plus être modifiées. LC_COLLATE et LC_CTYPE sont de cette catégorie. Elles affectent l'ordre de tri des index et doivent donc rester inchangées, les index sur les colonnes de texte risquant d'être corrompus dans le cas contraire. PostgreSQL™ s'en assure en enregistrant les valeurs de LC_COLLATE et LC_CTYPE vues par initdb. Le serveur adopte automatiquement ces deux valeurs au démarrage.

Les autres catégories de locale peuvent être modifiées au démarrage du serveur en fixant les variables d'environnement de même nom (voir la Section 17.10.2, « Locale et formatage » pour de plus amples détails). Les valeurs par défaut choisies par initdb sont en fait écrites dans le fichier de configuration postgresql.conf pour servir de valeurs par défaut au démarrage du serveur. Si ces déclarations sont supprimées du fichier postgresql.conf, le serveur hérite des paramètres de son environnement d'exécution.

Le comportement des locales du serveur est déterminé par les variables d'environnement vues par le serveur, pas par celles de l'environnement d'un quelconque client. Il est donc important de configurer les bons paramètres de locales avant le démarrage du serveur. Cela a pour conséquence que, si les locales du client et du serveur diffèrent, les messages peuvent apparaître dans des langues différentes en fonction de leur provenance.

Pour permettre la traduction des messages dans la langue préférée de l'utilisateur, NLS doit avoir été activé pendant la compilation. Ce choix est indépendant du support d'autres locales.

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

Le support des locales autres que C ou POSIX dans PostgreSQL™ a pour inconvénient 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 préférable de n'utiliser les locales qu'en cas de réel besoin.

Toutefois, pour permettre à PostgreSQL™ d'utiliser des index avec les clauses LIKE et une locale différente de C, il existe plusieurs classes d'opérateurs personnalisées. Elles permettent la création d'un index qui réalise une stricte comparaison caractère par caractère, ignorant les règles de comparaison des locales. Se référer à la Section 11.8, « Classes d'opérateurs » pour plus d'informations.

Si le support des locales ne fonctionne pas au regard des explications ci-dessus, il faut vérifier que le support des locales du système d'exploitation est correctement configuré. Pour vérifier les locales installées sur le système, on peut utiliser la commande locale -a, si elle est fournie avec le système d'exploitation.

Il faut vérifier que PostgreSQL™ utilise effectivement la locale supposée. Les paramètres LC_COLLATE et LC_CTYPE sont déterminés lors de l'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 peuvent être modifiés pendant l'exécution. Pour vérifier le paramétrage de la locale active on utilise la commande SHOW.

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

Les applications clientes qui gèrent les erreurs en provenance du serveur par l'analyse du texte du message d'erreur vont certainement éprouver des difficultés lorsque les messages du serveur sont dans une langue différente. Les auteurs de telles applications sont invités à utiliser le schéma de code d'erreur à la place.

Le maintien de catalogues de traductions de messages nécessitent les efforts permanents de beaucoup de volontaires qui souhaitent voir PostgreSQL™ parler correctement leur langue préférée. Si certains messages dans une langue ne sont pas disponibles ou pas complètement traduits, toute aide est la bienvenue. Pour apporter son aide à ce projet, consulter le Chapitre 46, Support natif des langues ou écrire à la liste de diffusion des développeurs.