20.1.1. Überblick

Die Locale-Unterstützung wird automatisch initialisiert, wenn ein Datenbankcluster mit initdb erzeugt wird. initdb initialisiert den Datenbankcluster mit den Locale-Einstellungen aus seiner Umgebung; wenn also Ihr System schon die Locale verwendet, die Sie in Ihrem Datenbankcluster verwenden wollen, dann müssen Sie nichts weiter tun. Wenn Sie eine andere Locale verwenden wollen (oder Sie sich nicht sicher sind, welche Ihr System verwendet), dann können Sie initdb mit der Option --locale genau sagen, welche Locale Sie verwenden wollen. Zum Beispiel:

initdb --locale=sv_SE

Dieses Beispiel setzt die Locale auf Schwedisch (sv) wie es in Schweden (SE) gesprochen wird. Weitere Beispiele sind de_DE (Deutsch, Deutschland), en_US (Englisch, USA) oder fr_CA (Französisch, Kanada). Wenn mehr als ein Zeichensatz für eine Locale verwendet werden kann, dann sieht die Angabe so aus: cs_CZ.ISO8859-2. Welche Locales auf Ihrem System vorhanden sind, hängt davon ab, was vom Hersteller zur Verfügung gestellt und installiert wurde.

Gelegentlich kann es nützlich sein, die Regeln aus mehreren Locales zu kombinieren, zum Beispiel englische Sortierreihenfolge aber spanische Meldungen. Um das zu ermöglichen, gibt es mehrere Locale-Subkategorien, die nur bestimmte Aspekte der Locale-Regeln kontrollieren.

Wenn Sie wollen, dass sich Ihr System so verhält, als hätte es keine Locale-Unterstützung, dann setzen Sie die Locale auf C oder POSIX.

Bei einigen Locale-Kategorien steht der Wert für die gesamte Lebensdauer des Datenbankclusters fest. Das heißt, nachdem initdb ausgeführt wurde, dann können Sie ihn nicht mehr verändern. Diese Kategorien sind LC_COLLATE und LC_CTYPE. Sie beeinflussen die Sortierreihenfolge der Indexe und müssen daher konstant gehalten werden oder Indexe für Textspalten werden verfälscht und ungültig werden. PostgreSQL sorgt dafür, dass die Locale-Werte konstant bleiben, indem die von initdb gesehenen Werte von LC_COLLATE und LC_CTYPE gespeichert werden. Der Server stellt diese beiden Werte dann automatisch ein, wenn er gestartet wird.

Die anderen Locale-Kategorien können während der Server läuft immer geändert werden, indem die Konfigurationsparameter mit den gleichen Namen wie die Locale-Kategorien eingestellt werden (siehe Abschnitt 16.4 wegen Einzelheiten). Die durch initdb gewählten Voreinstellungen werden nur in die Konfigurationsdatei postgresql.conf geschrieben, wo sie als Voreinstellungen dienen, wenn der Server gestartet wird. Wenn Sie die Zuweisungen aus postgresql.conf löschen, dann übernimmt der Server die Einstellungen aus der Umgebung.

Beachten Sie, dass das Locale-Verhalten des Servers von den vom Server gesehenen Umgebungsvariablen abhängt, und nicht von der Umgebung irgendeines Clients. Daher müssen Sie darauf achten, dass Sie die Locale-Einstellungen tätigen, bevor Sie den Server starten. Daraus folgt auch, wenn der Server und der Client verschiedene Locales verwenden, dann können Meldungen in verschiedenen Sprachen erscheinen, je nachdem woher sie stammen.

Um Mitteilungen in der vom Benutzer bevorzugten Sprache anzeigen zu können, muss NLS beim Compilieren angeschaltet worden sein. Diese Wahl ist unabhängig von der anderen Locale-Unterstützung.

20.1.2. Nutzen

Locale-Unterstützung hat insbesondere Auswirkung auf die folgenden Aspekte:

• Sortierreihenfolge in Anfragen mit ORDER BY

• Die Funktionsfamilie to_char

• Die Operatoren LIKE und ~ für Mustervergleiche

Der einzige schwerwiegende Nachteil der Locale-Unterstützung in PostgreSQL ist die Geschwindigkeit. Also verwenden Sie Locales nur, wenn Sie sie wirklich benötigen. Man sollte anmerken, dass die Auswahl einer anderen Locale außer C die Verwendung eines Index für die Operatoren LIKE und ~ verhindert, was für die Geschwindigkeit von Anfragen, die diese Operatoren verwenden, einen gewaltigen Unterschied machen kann.

20.1.3. Probleme

Wenn die Locale-Unterstützung trotz der Erklärung oben nicht funktioniert, dann überprüfen Sie, ob die Locale-Unterstützung in Ihrem Betriebssystem richtig läuft. Um zu sehen, welche Locales auf Ihrem System installiert sind, können Sie den Befehl locale -a verwenden, wenn Ihr Betriebssystem ihn zur Verfügung stellt.

Überprüfen Sie, ob PostgreSQL tatsächlich die Locale verwendet, die Sie denken. Die Einstellungen von LC_COLLATE und LC_CTYPE werden von initdb gemacht und können später nicht geändert werden ohne initdb zu wiederholen. Die anderen Locale-Kategorien werden anfänglich von der Umgebung, in der der Server gestartet wird, bestimmt. Die Einstellungen von LC_COLLATE und LC_CTYPE können Sie mit dem Hilfsprogramm pg_controldata einsehen.

Das Verzeichnis src/test/locale in der Quellendistribution enthält einige Tests für die Locale-Unterstützung in PostgreSQL.

Clientanwendungen, die Serverfehler verarbeiten, indem Sie den Text der Meldung analysieren, werden natürlich Probleme haben, wenn die Meldungen des Servers in einer anderen Sprache sind. Wenn Sie so eine Anwendung entwickeln, dann müssen Sie einen Plan aufstellen um mit dieser Situation fertig zu werden. Die Schnittstelle ECPG (eingebettetes SQL) ist von diesem Problem auch betroffen. Wenn ein Server mit ECPG-Anwendungen kommunizieren muss, dann wird gegenwärtig empfohlen, dass er so konfiguriert wird, dass er Meldungen auf Englisch schickt.

Die Pflege von Katalogen mit Übersetzungen der Programmmeldungen erfordert die andauernden Bemühungen vieler Freiwilliger, die wollen, dass PostgreSQL ihre bevorzugte Sprache gut sprechen kann. Wenn die Meldungen in einer Sprache gegenwärtig nicht angeboten werden oder nicht vollständig übersetzt sind, dann würde Ihre Hilfe sehr geschätzt werden. Wenn Sie helfen wollen, dann schreiben Sie an die Entwicklermailingliste.