ロケールのサポートはアルファベット、並び換え、数字の書式など文化的嗜好を配慮したアプリケーションを対象にします。 PostgreSQLは、サーバのオペレーティングシステムが提供する、標準ISO CとPOSIXのロケール機能を使用します。 これ以上の情報についてはお使いのシステムのドキュメントを参照してください。
ロケールのサポートは、initdbを使用してデータベースクラスタを作成する時に自動で初期化されます。
initdbは、デフォルトでその実行環境のロケール設定に従ってデータベースクラスタを初期化します。
そのため、システムがデータベースクラスタで使用したいロケールを使用するように既に設定してある場合は何も行う必要はありません。
違うロケールを使用したい場合（またはシステムのロケール設定が不明な場合）は、initdbの--localeオプションで希望のロケールを指定することができます。
以下に例を示します。
initdb --locale=sv_SE
Unixシステム用のこの例の設定はロケールをスウェーデン（SE）で使用されているスウェーデン語（sv）に合わせています。
他にもen_US（米国英語）やfr_CA（カナダのフランス語）などの設定もできます。
ロケールに複数の文字セットが使用可能であれば、language_territory.codesetのように記述することができます。
例えば、fr_BE.UTF-8はベルギー（BE）で使用されているフランス語（fr）でUTF-8の文字セットを表します。
お使いのシステムでどのロケールがどういう名前で使えるかはオペレーティングシステムのベンダがどのようなものを提供しているかと、何がインストールされているかに依存します。
ほとんどのUnixシステムでは、locale -aというコマンドで利用可能なロケールの一覧を入手できます。
Windowsは、German_GermanyやSwedish_Sweden.1252のようなもっと冗長なロケール名を使用しますが、原理は同じです。
英語の照合順序規則でスペイン語のメッセージを使用する時など、時として複数のロケールの規則を併用すると便利です。 これをサポートするために、ロケールには以下のような多言語対応規則の特定の箇所だけを管理する一連のサブカテゴリがあります。
LC_COLLATE | 文字列の並び換え順 |
LC_CTYPE | 文字の分類（文字とはどんなもの？大文字小文字を区別しない？） |
LC_MESSAGES | メッセージの言語 |
LC_MONETARY | 通貨書式 |
LC_NUMERIC | 数字の書式 |
LC_TIME | 日付と時刻の書式 |
これらのカテゴリの名前は、特定のカテゴリについてのロケールの選択を上書きするためのinitdbオプションの名前としてそのまま使用できます。
例えば、ロケールをカナダのフランス語に設定しながら通貨書式については米国の規則を使用するには、initdb --locale=fr_CA --lc-monetary=en_USとします。
システムがロケールをサポートしていないように動作させたい場合は、特別なロケールのC、もしくは同等なPOSIXを使用してください。
一部のロケールカテゴリでは、その値がデータベース生成時に固定されていなければならないものがあります。
他のデータベースで他の設定を使用することができますが、一度データベースが生成されると、そのデータベースでは変更することができません。
LC_COLLATEとLC_CTYPEがこれらのカテゴリにあてはまります。
これらはインデックスのソート順に影響を及ぼすため、固定されていなければなりません。
さもないと、テキスト型の列上のインデックスは破壊されるでしょう。
（しかし24.2内で述べられているように、照合順序を使用することで、この制限を緩和できます）
initdbが実行された時に、これらのカテゴリのデフォルト値は決定され、CREATE DATABASEコマンドで他を指定しない限り、新しいデータベースが作成されるときにこの値が使用されます。
その他のロケールカテゴリは、いつでも、ロケールカテゴリと同じ名前の実行時パラメータを設定することで、希望値に変更できます
（詳細は20.11.2を参照してください）。
initdbで選択された値は、実際のところ、サーバの起動時にデフォルトとして動作するようにpostgresql.conf設定ファイルに書き込まれるだけです。
この代入文をpostgresql.confから削除すると、サーバは実行環境の設定をそのまま使用します。
サーバのロケールの動作はどのクライアントの環境にも依存せず、サーバが参照できる環境変数で決まります。 ですからサーバを稼働させる前に正しいロケール設定を行うように注意してください。 結果としてサーバとクライアントで異なるロケールが設定されていると、メッセージはそれらがどこから生じたかによって、異なる言語で表示されます。
実行環境のロケールをそのまま使用するということは、ほとんどのオペレーティングシステムでは次のような意味を持ちます。
指定されたロケールカテゴリ（例えば照合順序）について、設定するものが見つかるまで、以下の環境変数がこの順番で調べられます。LC_ALL、LC_COLLATE（またはそれぞれのカテゴリに対応する変数）、LANG。
これらのいずれの環境変数も設定されない場合に、ロケールはデフォルトでCに設定されます。
メッセージの言語を設定する目的で、メッセージ多言語化ライブラリの中には全てのロケール設定を上書きする環境変数LANGUAGEを検索するものがあります。
お使いのシステムでの挙動が不明ならばより詳細な情報を得るためお使いのオペレーティングシステムの文書、特にgettextの文書を参照してください。
ユーザの選択した言語にメッセージを翻訳できるようにするためにはNLSを構築時に有効にする（configure --enable-nls）必要があります。
他のロケールサポートはすべて自動的に構築されます。
ロケールの設定は以下のSQL機能に影響を与えます。
CやPOSIX以外で、PostgreSQLでロケールを使用する際の欠点は実行速度です。
ロケールは文字の扱いを遅くし、さらにLIKEで通常のインデックスが使用されなくなります。この理由から、本当に必要な時のみロケールを使用してください。
C以外のロケールにおいて、PostgreSQLがLIKE句を持つインデックスを使用できるようにする回避方法として、いくつかのカスタム演算子クラスがあります。
これらを用いると、文字と文字を厳密に比較するようなインデックスや、ロケールの比較規則を無視するようなインデックスを作成できます。
詳細は11.10を参照してください。
もうひとつの方法は、24.2内で解説されているようなC照合順序を使用してインデックスを作成することです。
ロケールは、要件に応じて異なる範囲で選択できます。
前述の概要では、initdbを使用してロケールを指定し、クラスタ全体のデフォルトを設定する方法を説明しました。
次のリストは、ロケールを選択できる場所を示しています。
各項目は後続の項目のデフォルトを提供し、下位の各項目はより細かい粒度でデフォルトを上書きできます。
上で説明したように、オペレーティングシステムの環境は、新しく初期化されたデータベースクラスタのロケールのデフォルトを提供します。 多くの場合、これで十分です。 オペレーティングシステムが目的の言語/地域に設定されている場合、PostgreSQLもデフォルトでそのロケールに従って動作します。
上記のように、initdbのコマンドラインオプションでは、新しく初期化されたデータベースクラスタのロケール設定を指定します。
オペレーティングシステムにデータベースシステムに必要なロケール設定がない場合に使用します。
ロケールはデータベースごとに個別に選択できます。
SQLコマンドCREATE DATABASEとそれに相当するコマンドラインcreatedbには、そのためのオプションがあります。
これは、データベース・クラスタに、異なる要件を持つ複数のテナントのデータベースが格納されている場合などに使用します。
ロケール設定は、個々のテーブル列に対して行うことができます。 これは照合順序というSQLオブジェクトを使用します。 このオブジェクトは24.2で説明されています。 たとえば、異なる言語でデータをソートしたり、特定のテーブルのソート順をカスタマイズする場合に使用します。
最後に、個々の問い合わせに対してロケールを選択できます。 ここでも、SQL照合オブジェクトを使用します。 これは、実行時の選択に基づいて並べ替え順序を変更する場合や、アドホックな実験に使用できます。
PostgreSQLは複数のロケールプロバイダをサポートします。
これによってどのライブラリがロケールデータを提供するかを決定します。
標準プロバイダの一つはlibcで、オペレーティングシステムのCライブラリが提供するロケールを使用します。
これらのロケールは、オペレーティングシステムが提供するほとんどのツールが使用します。
他のプロバイダとしてはicuがあり、外部のICUライブラリを使います。
ICUロケールは、PostgreSQLがビルドされた際にICUサポートが設定されていた場合にのみ利用可能です。
前述のように、ロケール設定を選択するコマンドおよびツールには、それぞれロケール・プロバイダを選択するオプションがあります。
前述の例では、デフォルトであるlibcプロバイダを使用しています。
次に、ICUプロバイダを使用してデータベース・クラスタを初期化する例を示します:
initdb --locale-provider=icu --icu-locale=en
詳細は、各コマンドおよびプログラムの説明を参照してください。
異なる粒度でロケール・プロバイダを混在させることもできます。
たとえば、クラスタではデフォルトでlibcを使用しますが、icuプロバイダを使用するデータベースが1つあり、これらのデータベース内でいずれかのプロバイダを使用する照合オブジェクトがあることに注意してください。
どのロケールプロバイダを使用するかは、個々の要件によって異なります。 ほとんどの基本的な使用方法では、どちらのプロバイダでも十分な結果が得られます。 libcプロバイダの場合は、オペレーティングシステムが提供するものによって異なります。 オペレーティングシステムによっては、より優れたものもあります。 高度な使用方法では、ICUはより多くのロケールバリエーションとカスタマイズオプションを提供します。
上記の説明に従ってロケールのサポートが正常に動作しない場合、オペレーティングシステムのロケールサポートが正確に設定されているか確認してください。
指定されたロケールがインストールされているかどうか確認するために、オペレーティングシステムが提供していれば、locale -aコマンドを使用することができます。
PostgreSQLが想定しているロケールを実際に使用しているかどうかを確認してください。
LC_COLLATEとLC_CTYPEの設定はデータベース作成時に決定され、新しいデータベースを作成する方法以外に変更することはできません。
LC_MESSAGESやLC_MONETARYなど他のロケール設定はサーバ起動時の環境変数によって初めに決定されますが、その場で変更することもできます。
SHOWコマンドを使用して、使用中のロケール設定を確認できます。
ソース配布物のsrc/test/localeディレクトリには、PostgreSQLのロケールサポート用の試験一式があります。
エラーメッセージ内のテキストを解析してサーバ側のエラーを扱っているクライアントアプリケーションでは、サーバのメッセージが異なる言語で記載されると、明らかに問題になります。 こうしたアプリケーションの作者には、エラーコードスキームで代替させることを推奨します。
メッセージ翻訳のカタログのメンテナンスにはPostgreSQLに選択した言語を話させてみたいという数多くのボランティアのたゆみのない努力を必要としています。 もしあなたの言語が現在使えなかったり完全に翻訳されていない場合、助力をよろしくお願いします。 もし助力していただけるのであれば、第57章を参照するか開発グループのメーリングリストに投稿してください。