他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

24.1. ロケールのサポート #

ロケールのサポートはアルファベット、並べ替え、数字の書式など文化的嗜好を配慮したアプリケーションを対象にします。 PostgreSQLは、サーバのオペレーティングシステムが提供する、標準ISO CとPOSIXのロケール機能を使用します。 これ以上の情報についてはお使いのシステムのドキュメントを参照してください。

24.1.1. 概要 #

ロケールのサポートは、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_GermanySwedish_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_COLLATELC_CTYPEがこれらのカテゴリにあてはまります。 これらはインデックスのソート順に影響を及ぼすため、固定されていなければなりません。 さもないと、テキスト型の列上のインデックスは破壊されるでしょう。 (しかし24.2内で述べられているように、照合順序を使用することで、この制限を緩和できます) initdbが実行された時に、これらのカテゴリのデフォルト値は決定され、CREATE DATABASEコマンドで他を指定しない限り、新しいデータベースが作成されるときにこの値が使用されます。

その他のロケールカテゴリは、いつでも、ロケールカテゴリと同じ名前の実行時パラメータを設定することで、希望値に変更できます (詳細は20.11.2を参照してください)。 initdbで選択された値は、実際のところ、サーバの起動時にデフォルトとして動作するようにpostgresql.conf設定ファイルに書き込まれるだけです。 この代入文をpostgresql.confから削除すると、サーバは実行環境の設定をそのまま使用します。

サーバのロケールの動作はどのクライアントの環境にも依存せず、サーバが参照できる環境変数で決まります。 ですからサーバを稼働させる前に正しいロケール設定を行うように注意してください。 結果としてサーバとクライアントで異なるロケールが設定されていると、メッセージはそれらがどこから生じたかによって、異なる言語で表示されます。

注記

実行環境のロケールをそのまま使用するということは、ほとんどのオペレーティングシステムでは次のような意味を持ちます。 指定されたロケールカテゴリ(例えば照合順序)について、設定するものが見つかるまで、以下の環境変数がこの順番で調べられます。LC_ALLLC_COLLATE(またはそれぞれのカテゴリに対応する変数)、LANG。 これらのいずれの環境変数も設定されない場合に、ロケールはデフォルトでCに設定されます。

メッセージの言語を設定する目的で、メッセージローカライゼーションライブラリの中には全てのロケール設定を上書きする環境変数LANGUAGEを検索するものがあります。 お使いのシステムでの挙動が不明ならばより詳細な情報を得るためお使いのオペレーティングシステムの文書、特にgettextの文書を参照してください。

ユーザの選択した言語にメッセージを翻訳できるようにするためにはNLSを構築時に有効にする(configure --enable-nls)必要があります。 他のロケールサポートはすべて自動的に構築されます。

24.1.2. 動作 #

ロケールの設定は以下のSQL機能に影響を与えます。

  • 文字列データに対するORDER BYまたは標準の比較演算子を使用した問い合わせにおける並べ替え順

  • upperlowerinitcap関数

  • LIKESIMILAR TOやPOSIX形式の正規表現といった)パターンマッチング演算子では ロケールは大文字、小文字を区別せず正規表現の文字クラスによる文字の区別に影響を及ぼします。

  • 一群のto_char関数

  • LIKE節が付いたインデックスを使用する性能

CPOSIX以外で、PostgreSQLでロケールを使用する際の欠点は実行速度です。 ロケールは文字の扱いを遅くし、さらにLIKEで通常のインデックスが使用されなくなります。この理由から、本当に必要な時のみロケールを使用してください。

C以外のロケールにおいて、PostgreSQLLIKE句を持つインデックスを使用できるようにする回避方法として、いくつかのカスタム演算子クラスがあります。 これらを用いると、文字と文字を厳密に比較するようなインデックスや、ロケールの比較規則を無視するようなインデックスを作成できます。 詳細は11.10を参照してください。 もうひとつの方法は、24.2内で解説されているようなC照合順序を使用してインデックスを作成することです。

24.1.3. ロケールの選択 #

ロケールは、要件に応じて異なる範囲で選択できます。 前述の概要では、initdbを使用してロケールを指定し、クラスタ全体のデフォルトを設定する方法を説明しました。 次のリストは、ロケールを選択できる場所を示しています。 各項目は後続の項目のデフォルトを提供し、下位の各項目はより細かい粒度でデフォルトを上書きできます。

  1. 上で説明したように、オペレーティングシステムの環境は、新しく初期化されたデータベースクラスタのロケールのデフォルトを提供します。 多くの場合、これで十分です。 オペレーティングシステムが目的の言語/地域に設定されている場合、PostgreSQLもデフォルトでそのロケールに従って動作します。

  2. 上記のように、initdbのコマンドラインオプションでは、新しく初期化されたデータベースクラスタのロケール設定を指定します。 オペレーティングシステムにデータベースシステムに必要なロケール設定がない場合に使用します。

  3. ロケールはデータベースごとに個別に選択できます。 SQLコマンドCREATE DATABASEとそれに相当するコマンドラインcreatedbには、そのためのオプションがあります。 これは、データベース・クラスタに、異なる要件を持つ複数のテナントのデータベースが格納されている場合などに使用します。

  4. ロケール設定は、個々のテーブル列に対して行うことができます。 これは照合順序というSQLオブジェクトを使用します。 このオブジェクトは24.2で説明されています。 たとえば、異なる言語でデータをソートしたり、特定のテーブルのソート順をカスタマイズする場合に使用します。

  5. 最後に、個々の問い合わせに対してロケールを選択できます。 ここでも、SQL照合オブジェクトを使用します。 これは、実行時の選択に基づいて並べ替え順序を変更する場合や、アドホックな実験に使用できます。

24.1.4. ロケールプロバイダ #

PostgreSQLは複数のロケールプロバイダをサポートします。 これによってどのライブラリがロケールデータを提供するかを決定します。 標準プロバイダの一つはlibcで、オペレーティングシステムのCライブラリが提供するロケールを使用します。 これらのロケールは、オペレーティングシステムが提供するほとんどのツールが使用します。 他のプロバイダとしてはicuがあり、外部のICUライブラリを使います。 ICUロケールは、PostgreSQLがビルドされた際にICUサポートが設定されていた場合にのみ利用可能です。

前述のように、ロケール設定を選択するコマンドおよびツールには、それぞれロケール・プロバイダを選択するオプションがあります。 前述の例では、デフォルトであるlibcプロバイダを使用しています。 次に、ICUプロバイダを使用してデータベース・クラスタを初期化する例を示します:

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

詳細は、各コマンドおよびプログラムの説明を参照してください。 異なる粒度でロケール・プロバイダを混在させることもできます。 たとえば、クラスタではデフォルトでlibcを使用しますが、icuプロバイダを使用するデータベースが1つあり、これらのデータベース内でいずれかのプロバイダを使用する照合オブジェクトがあることに注意してください。

どのロケールプロバイダを使用するかは、個々の要件によって異なります。 ほとんどの基本的な使用方法では、どちらのプロバイダでも十分な結果が得られます。 libcプロバイダの場合は、オペレーティングシステムが提供するものによって異なります。 オペレーティングシステムによっては、より優れたものもあります。 高度な使用方法では、ICUはより多くのロケールバリエーションとカスタマイズオプションを提供します。

24.1.5. ICUロケール #

24.1.5.1. ICUロケール名 #

ロケール名のICU形式は言語タグです。

CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP');
CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');

24.1.5.2. ロケールの正規化と検証 #

ICUをプロバイダとして使用して新しいICU照合順序オブジェクトまたはデータベースを定義する場合、指定されたロケール名がその形式でない場合は、言語タグに変換 ("正規化") されます。 例えば、

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"

この通知が表示された場合は、providerlocaleが期待通りであることを確認してください。 ICUプロバイダを使用するときに一貫した結果を得るには、変換に依存するのではなく、標準の言語タグを指定してください。

言語名のないロケール、または特別言語名rootは、言語und("undefined")を持つように変換されます。

ICUでは、ほとんどのlibcロケール名とその他の形式を言語タグに変換して、ICUへの移行を容易にすることができます。 ICUでlibcロケール名を使用すると、libcでの動作とまったく同じであるとは限りません。

ロケール名の解釈に問題がある場合、またはロケール名をICUが認識しない言語または地域を表す場合は、次の警告が表示されます。

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は、メッセージがどのように報告されるかを制御します。 ERRORに設定されていない限り、照合順序は作成されますが、ユーザが意図した動作とは異なる可能性があります。

24.1.5.3. 言語タグ #

BCP 47で定義されている言語タグは、言語、識別子、およびロケールに関するその他の情報を識別するために使用される標準化された地域です。

基本言語タグは、単にlanguage-region、または単にlanguageです。 languageは言語コード(例:frはフランス語を表します)で、regionは地域コード(例:caはカナダを表します)です。 例:ja-JPde、またはfr-CA

照合順序設定を言語タグに含めて、照合順序の動作をカスタマイズすることができます。 ICUでは、アクセント、大文字小文字、句読点に対する感度(または非感度)、テキスト内の数字の扱いなど、さまざまな用途に対応するための多くのオプションを含む、照合順序の広範なカスタマイズが可能です。

言語タグにこの追加の照合順序情報を含めるには、追加の照合順序設定があることを示す-uを追加し、その後に1つ以上の-key-valueペアを続けます。 key照合順序設定のキーで、valueはその設定の有効な値です。 ブール設定の場合、-keyを指定するだけで、対応する-valueを指定しないことができ、これはtrueの値を意味します。

例えば、言語タグen-US-u-kn-ks-level2とは、米国の英語言語を持つロケールを意味し、照合順序設定kntrueに設定され、ksレベル2に設定されています。 これらの設定は、照合順序が大文字小文字を区別せず、続きの数字を単一の数値として扱うことを意味します。

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)

ロケールのためのカスタム照合順序情報を持つ言語タグの使用の詳細と追加の例については、24.2.3を参照してください。

24.1.6. 問題点 #

上記の説明に従ってロケールのサポートが正常に動作しない場合、オペレーティングシステムのロケールサポートが正確に設定されているか確認してください。 指定されたロケールがインストールされているかどうか確認するために、オペレーティングシステムが提供していれば、locale -aコマンドを使用することができます。

PostgreSQLが想定しているロケールを実際に使用しているかどうかを確認してください。 LC_COLLATELC_CTYPEの設定はデータベース作成時に決定され、新しいデータベースを作成する方法以外に変更することはできません。 LC_MESSAGESLC_MONETARYなど他のロケール設定はサーバ起動時の環境変数によって初めに決定されますが、その場で変更することもできます。 SHOWコマンドを使用して、使用中のロケール設定を確認できます。

ソース配布物のsrc/test/localeディレクトリには、PostgreSQLのロケールサポート用のテストスイートがあります。

エラーメッセージ内のテキストを解析してサーバ側のエラーを扱っているクライアントアプリケーションでは、サーバのメッセージが異なる言語で記載されると、明らかに問題になります。 こうしたアプリケーションの作者には、エラーコードスキームで代替させることを推奨します。

メッセージ翻訳のカタログのメンテナンスにはPostgreSQLに選択した言語を話させてみたいという数多くのボランティアのたゆみのない努力を必要としています。 もしあなたの言語が現在使えなかったり完全に翻訳されていない場合、助力をよろしくお願いします。 もし助力していただけるのであれば、第57章を参照するか開発グループのメーリングリストに投稿してください。