Le support des locales fait référence à une application respectant les préférences culturelles portant sur les alphabets, le tri, le format des nombres, etc. PostgreSQL utilise les outils C et POSIX du standard ISO fournis par le système d'exploitation du serveur. Pour plus d'informations, consulter la documentation du système.
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 :
LC_COLLATE | Ordre de tri des chaînes de caractères |
LC_CTYPE | Classification de caractères (Qu'est-ce qu'une lettre ? Et la majuscule équivalente ?) |
LC_MESSAGES | Langue des messages |
LC_MONETARY | Formatage des valeurs monétaires |
LC_NUMERIC | Formatage des nombres |
LC_TIME | Formatage des dates et heures |
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 23.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 19.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.
Hériter la locale de l'environnement d'exécution signifie, sur la
plupart des systèmes d'exploitation, la chose suivante :
pour une catégorie de locales donnée (disons la collation)
les variables d'environnement suivantes sont consultées dans cet ordre
jusqu'à en trouver une qui est définie :
LC_ALL,
LC_COLLATE (ou la variable correspondant à la catégorie)
et LANG. Si aucune de ces variables n'est définie,
la locale devient par défaut C.
Certaines bibliothèques de localisation regardent aussi la variable
d'environnement LANGUAGE, laquelle surcharge tout autre
paramètre pour fixer la langue des messages. En cas de doute,
lire la documentation du système d'exploitation,
en particulier la partie concernant gettext.
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'ordre de tri dans les requêtes utilisant ORDER BY
ou les opérateurs de comparaison standards sur des données de type
texte ;
les opérateurs de correspondance de motifs (LIKE, SIMILAR TO
et les expressions rationnelles de type POSIX) les locales affectent
les opérateurs insensibles à la classe, et le classement des caractères par les expressions
rationnelles portant sur des caractères ;
l'utilisation d'index avec des clauses LIKE.
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 23.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.
Comme expliqué ci-dessus, l'environnement du système d'exploitation fournit les valeurs par défaut pour les locales d'une instance tout juste initialisée. Dans de nombreux cas, c'est suffisant : si le système d'exploitation est configuré pour le langage/territoire désiré, alors PostgreSQL se comportera par défaut suivant cette locale.
Comme affiché ci-dessus, les options en ligne de commande
d'initdb indiquent les paramétrages de la locale pour
une instance tout juste initialisée. Utilisez-les si le système
d'exploitation n'a pas la configuration de locale que vous souhaitez pour
votre système de bases de données.
Une locale peut être sélectionnée séparément pour chaque base de données.
La commande SQL CREATE DATABASE et son équivalent en
ligne de commande, createdb, ont des options pour cela.
Utilisez-la par exemple si une instance contient des bases avec plusieurs
propriétaires ayant des besoins différents.
Les configurations de locale peuvent être faites pour les colonnes individuelles des tables. Il faut passer par un objet SQL appelé une collation, qui est expliqué dans Section 23.2. Utilisez-la par exemple pour trier des données dans différentes langues ou pour personnaliser l'ordre de tri d'une table particulière.
Enfin, les locales peuvent être sélectionnées pour une requête individuelle. De nouveau, cela utilise des objets SQL de collation. Cela permet de modifier l'ordre de tri en se basant sur un choix au moment de l'exécution ou pour une expérimentation.
Un fournisseur de locale spécifie la bibliothèque qui définit le comportement de la locale pour les classifications de collation et de caractères.
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. 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.
Quelque soit le fournisseur de la locale, le système d'exploitation est toujours utilisé pour fournir un certain comportement dépendant de la locale, tels que les messages (voir lc_messages).
Les fournisseurs de locale disponibles sont listés ci-dessous :
builtin
Le fournisseur builtin utilise des opérations
internes. Seules les locales C et
C.UTF-8 sont supportées par ce fournisseur.
Le comportement de la locale C est identique au
comportement de la locale C du fournisseur libc.
Lors de l'utilisation de cette locale, le comportement pourrait
dépendre de l'encodage de la base.
La locale C.UTF-8 est disponible uniquement quand
l'encodage de la base est UTF-8, et le comportement
est basé sur Unicode. La collation utilise uniquement les valeurs des
codes points. Les classes de caractères pour les expressions
rationnelles sont basés sur les sémantiques "POSIX Compatible",
et la correspondance de casse est le variant simple.
icu
Le fournisseur icu utilise la bibliothèque externe
ICU.
PostgreSQL doit avoir été compilé en
conséquence.
ICU fournit le comportement de classification de la collation et des
caractères du système d'exploitation et de l'encodage de base, qui est
préférable si vous vous attendez à changer vers d'autres plateformes
sans changement dans les résultats. LC_COLLATE et
LC_CTYPE peuvent être configurés indépendamment de
la locale ICU.
Pour le fournisseur ICU, les résultats peuvent dépendre de la version utilisée pour la bilbliothèque ICU car elle est mise à jour pour refléter les changements dans les langues.
libc
Le fournisseur libc utilise la bibliothèque C
du système d'exploiration. Le comportement de classification de
la collation et des caractères est contrôlé par les paramètres
LC_COLLATE et
LC_CTYPE, donc elles ne peuvent pas être
configurées indépendamment.
Le même nom de locale pourrait avoir un comportement différent sur des plateformes différentes utilisant le fournisseur libc.
Le format ICU pour les noms de locale est une étiquette de langage.
CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP'); CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');
Quand un nouvel objet collation ICU ou base de données avec un fournisseur ICU est défini, le nom donné de la locale est transformé (« canonisé ») en une étiquette de langage s'il n'est pas déjà sous cette forme. Par exemple,
CREATE COLLATION mycollation3 (provider = icu, locale = 'en-US-u-kn-true'); NOTICE: using standard form "en-US-u-kn" for locale "en-US-u-kn-true" CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8'); NOTICE: using standard form "de-DE" for locale "de_DE.utf8"
Si vous voyez cette notification, assurez vous que le fournisseur
et la locale sont bien le résultat attendu. Pour des résultats
cohérents lors de l'utilisation du fournisseur ICU, spécifiez l'étiquette de langage
canonique au lieu de s'appuyer sur la transformation.
Une locale sans nom de langage, ou le nom de langage spécial
root, est transformée pour avoir le langage
und ("indéfini").
ICU peut transformer la plupart des noms de locales libc, ainsi que d'autre formats, en étiquette de langage pour faciliter la transition vers ICU. Si un nom de locale libc est utilisé en ICU, il peut ne pas avoir exactement le même comportement qu'en libc.
S'il y a un problème d'interprétation de nom de locale, ou si le nom de locale représente un langage ou une région non reconnus par ICU, vous verrez l'avertissement suivant :
CREATE COLLATION nonsense (provider = icu, locale = 'nonsense'); WARNING: ICU locale "nonsense" has unknown language "nonsense" HINT: To disable ICU locale validation, set parameter icu_validation_level to DISABLED. CREATE COLLATION
icu_validation_level contrôle comment le message est
affiché. À moins qu'il soit affiché à ERROR, la collation
sera toujours créée,
mais le comportement pourrait ne pas être ce qui est attendu par l'utilisateur.
Une étiquette de langage, définie en BCP 47, est un identifiant standardisé utilisé pour identifier les langages, régions et autres informations à propos d'une locale.
Les étiquettes de langage basiques sont simplement
langage-région ;
ou même juste langage. Le
langage est un code de langage
(i.e. fr pour le français), et
région est un code de région
(i.e. CA pour le Canada). Par exemple :
ja-JP, de ou
fr-CA.
Les paramètres de collation peuvent être inclus dans l'étiquette de langage pour personnaliser le comportement de la collation. ICU permet une personnalisation étendue, telle que la sensibilité (ou insensibilité) aux accents, casse, et ponctuation ; traitement des chiffres à l'intérieur du texte ; et bien d'autres options pour satisfaire une variété de cas d'usage.
Pour inclure ces informations de collation supplémentaires dans une étiquette
de langage, ajouter -u,
qui indique qu'il y a des paramètres supplémentaires de collation, suivi par une ou
plusieurs paires
-clé-valeur
La clé est la clé pour le paramètre de collation et
valeur est la valeur valide pour ce paramètre. Pour les
paramètres booléens, la -clé
peut être spécifiée sans -valeur
correspondante, ce qui implique une valeur à true.
Par exemple, l'étiquette de langage en-US-u-kn-ks-level2
signifie une locale avec le langage Anglais dans la région US, avec des paramètres
de collation kn affecté à true et
ks affecté à level2. Ces paramètres
signifient que la collation sera insensible à la casse et traitera une séquence
de chiffres comme un nombre unique :
CREATE COLLATION mycollation5 (provider = icu, deterministic = false, locale = 'en-US-u-kn-ks-level2'); SELECT 'aB' = 'Ab' COLLATE mycollation5 as result; result -------- t (1 row) SELECT 'N-45' < 'N-123' COLLATE mycollation5 as result; result -------- t (1 row)
Voir Section 23.2.3 pour les détails et exemples supplémentaires d'utilisation des étiquettes de langage avec informations personalisées des collations pour la locale.
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 55, ou écrivez à la liste de diffusion des développeurs.