Le support des locales est configuré automatiquement lorsqu'une instance de base de données est créée avec initdb. initdb initialise l'instance avec la valeur de locale 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 l'on désire une locale différente, ou si celle du serveur n'est pas connue avec certitude, il est possible d'indiquer à initdb la locale à l'aide de l'option --locale. Par exemple :

initdb --locale=sv_SE

Cet exemple pour les systèmes Unix positionne la locale au suédois (sv), tel que parlé en Suède (SE). Parmi les autres possibilités, on peut inclure en_US (l'anglais américain) ou fr_CA (français canadien). Si plusieurs ensembles de caractères peuvent être utilisés pour une locale, alors les spécifications peuvent prendre la forme langage_territoire.codeset. Par exemple, fr_BE.UTF-8 représente la langue française, telle qu'elle est parlée en Belgique (BE), avec un encodage UTF-8.

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 Unix, la commande locale -a fournit la liste des locales disponibles. Windows utilise des noms de locale plus verbeux, comme German_Germany ou Swedish_Sweden.1252, mais le principe est le même.

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 que certains aspects des règles de localisation :

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

Si vous voulez un système qui se comporte comme s'il n'avait aucun support des locales, utilisez les locales spéciales C, ou l'équivalent POSIX.

Certaines catégories de locales doivent être fixées à la création de la base de données. Elles peuvent différer entre bases de données, mais, une fois la base créée, elles ne peuvent plus être modifiées. LC_COLLATE et LC_CTYPE sont ces catégories. 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. (Mais vous pouvez lever ces restrictions grâce aux collations, comme discuté dans Section 24.2.) Les valeurs par défaut de ces catégories sont déterminées à l'exécution d'initdb, et utilisées à la création de nouvelles bases de données, sauf indication contraire dans la commande CREATE DATABASE.

Les autres catégories de locale peuvent être modifiées à n'importe quel moment en configurant les variables d'environnement de même nom (voir Section 20.11.3 pour de plus amples détails). Les valeurs choisies par initdb sont en fait juste écrites dans le fichier de configuration postgresql.conf pour servir de valeurs par défaut au démarrage du serveur. Si elles sont supprimées du fichier postgresql.conf, le serveur hérite des paramètres de son environnement d'exécution.

Notez que les locales du serveur sont déterminées 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. En conséquence, 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é à la compilation (configure --enable-nls). Le reste de l'outillage des locales est automatiquement inclus.

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

L'inconvénient du support dans PostgreSQL des locales (autres que C ou POSIX) est l'impact sur les performances. Il ralentit la gestion des caractères, et empêche l'utilisation des index ordinaires lors d'un LIKE. Pour cette raison, il est préférable de n'utiliser les locales qu'en cas de réel besoin.

Toutefois, il existe plusieurs classes d'opérateurs personnalisées pour permettre à PostgreSQL d'utiliser des index avec les clauses LIKE et une locale autre que C. Ces classes permettent la création d'un index réalisant une stricte comparaison caractère par caractère, en ignorant les règles de comparaison des locales ; se référer à la Section 11.10 pour plus d'informations. Une autre possibilité est de créer des index en utilisant la collation C, comme discuté dans Section 24.2.

Les locales peuvent être sélectionnées dans différentes configurations suivant les besoins. L'aperçu ci-dessus montrait comment les locales sont spécifiées en utilisant initdb pour configurer les valeurs par défaut pour l'instance complète. La liste suivante montre où les locales peuvent être sélectionnées. Chaque élément fournit les valeurs par défaut pour les éléments suivants, et chaque élément inférieur permet de surcharger les valeurs par défaut sur une granularité plus fine.

PostgreSQL accepte plusieurs fournisseurs de locale. Elle indique la bibliothèque qui fournit les données de locale. Un nom de fournisseur standard est libc, qui utilise les locales fournies par la bibliothèque C du système d'exploitation. Ce sont les locales utilisées par la plupart des outils fournis par le système d'exploitation. Un autre fournisseur est icu, qui utilise la bibliothèque externe ICU. Les locales ICU peuvent seulement être utilisées si le support d'ICU a été configuré lors de la construction de PostgreSQL.

Les commandes et outils qui sélectionnent les paramètres de la locale, comme décrit ci-dessus, ont tous une option pour sélectionner le fournisseur de la locale. Les exemples montrés ci-dessus utilisent le fournisseur libc, qui est le fournisseur par défaut. Voici un exemple pour initialiser une instance de bases en utilisant le fournisseur ICU :

initdb --locale-provider=icu --icu-locale=en

Voir la description des commandes et programmes respectifs pour les détails. Notez que vous pouvez mélanger les fournisseurs de locale sur différentes granularités, par exemple utiliser libc par défaut pour l'instance, mais avoir une base qui utilise le fournisseur icu, puis avoir les objets de collation utilisant un des fournisseurs dans ces bases.

Le fournisseur de locale à utiliser dépend des besoins individuels. Pour des utilisations basiques, chaque fournisseur donnera des résultats adéquats. Pour le fournisseur libc, il dépend de ce qu'offre le système d'exploitation ; certains systèmes d'exploitation sont meilleurs que d'autres. Pour des utilisations avancées, ICU offre plus de variants de locale et plus d'options de personnalisation.

Si le support des locales ne fonctionne pas au regard des explications ci-dessus, vérifiez que le support au niveau 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 que vous pensez. Les paramètres LC_COLLATE et LC_CTYPE sont déterminés lors de la création de la base de données, et ne peuvent pas être modifiés, sauf en créant une nouvelle base de données. 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 la locale active, utilisez 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.

Certaines applications clientes, qui gèrent les erreurs en provenance du serveur en analysant le texte des messages associés, auront évidemment des problèmes lorsque ces messages du serveur seront dans une autre langue. Les auteurs de telles applications sont invités à utiliser plutôt le mécanisme de code d'erreur.

Le maintien de catalogues de traduction des messages nécessite les efforts permanents de beaucoup de volontaires souhaitant 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 votre aide à ce projet, consultez le Chapitre 57, ou écrivez à la liste de diffusion des développeurs.