バージョンごとのドキュメント一覧

23.2. 照合順序サポート #

<title>Collation Support</title>

The collation feature allows specifying the sort order and character classification behavior of data per-column, or even per-operation. This alleviates the restriction that the <symbol>LC_COLLATE</symbol> and <symbol>LC_CTYPE</symbol> settings of a database cannot be changed after its creation. 照合順序機能は、ソート順番と列ごともしくは操作ごとのデータの文字区別の振る舞いを指定することを可能にします。 これにより、作成後のデータベースのLC_COLLATELC_CTYPEの設定を変更できない制限が緩和されます。

23.2.1. 概念 #

<title>Concepts</title>

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are <type>text</type>, <type>varchar</type>, and <type>char</type>. User-defined base types can also be marked collatable, and of course a <glossterm linkend="glossary-domain">domain</glossterm> over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below. 概念的に照合可能なデータ型のそれぞれの式は、照合順序を保持しています (組み込みの照合可能なデータ型はtextvarcharcharです。 ユーザ定義の基本型は照合可能とマーキングできます。もちろん照合可能なデータ型上のドメインは照合可能となります)。 もし、式が列参照である場合は、式の照合順序は列の定義された照合順序となります。 もし、式が定数である場合は、照合順序は定数のデータ型のデフォルトの照合順序となります。 より複雑な式の照合順序は、下記に示すように、その入力の照合順序から引き出されます。

The collation of an expression can be the <quote>default</quote> collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail. 式の照合順序は、default照合順序となります。これはデータベースに対して定義されたロケール設定を意味しています。 式の照合順序は非決定となることもあります。そのような場合に、照合順序が必要となるような順序操作や他の操作は失敗するでしょう。

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with <literal>ORDER BY</literal> clauses and function or operator calls such as <literal>&lt;</literal>. The collation to apply for an <literal>ORDER BY</literal> clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as <function>lower</function>, <function>upper</function>, and <function>initcap</function>; by pattern matching operators; and by <function>to_char</function> and related functions. データベースシステムが並べ替えや文字区別を行う場合、データベースは入力の照合順序を使用します。 これは、たとえばORDER BY句や < 演算子や関数を使用する際に発生します。 ORDER BY句に適用する照合順序は、単純にソートキーの照合順序です。 関数や演算子の呼び出しに対して適用される照合順序は、以下に述べるように引数により決まります。 比較演算子に加えて、照合順序はlowerupperinitcapといった小文字と大文字を変換する関数やパターンマッチングの演算子、to_char関連の関数で考慮されています。

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation. 関数や演算子の呼び出しに対して、引数の照合順序検査により得られた照合順序は実行時に特定の操作を行うために使用されます。 もし関数や演算子の呼び出しの結果が照合順序可能なデータ型であった場合、照合順序は関数もしくは演算子式の定義済みの照合順序として 解析時にも試用されます。このとき照合順序の知識が必要となるような囲み式があります。

The <firstterm>collation derivation</firstterm> of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a <literal>COLLATE</literal> clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used: 式の照合順序の導出は暗黙でも明示的にでも可能です。 この区別は、複数の異なる照合順序が式中に現れるときに照合順序がどのように組み合わされるか、に影響を与えます。 明示的な照合順序の導出は、COLLATE句が使用されたときに発生します。 他の全ての照合順序は暗黙となります。例えば関数呼び出しの中では、次の規則が用いられます。

  1. If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination. 入力式に明示的な照合順序の導出がある場合、入力式の中の明示的に導出された全ての照合順序が同一でなくてはなりません。 そうでない場合はエラーが発生します。もし明示的に導出された照合順序がある場合は、それは照合順序の組み合わせの結果となります。

  2. Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation. そうでない場合は、全ての入力式は同一の暗黙の照合順序の導出またはデフォルトの照合順序を持たなくてはなりません。 もしデフォルトではない照合順序がある場合は、それは照合順序の組み合わせの結果となります。 もしそうでない場合は、結果はデフォルトの照合順序となります。

  3. If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time. 入力式内でデフォルトではない暗黙の照合順序が衝突している場合、決定不能な照合順序であるとみなされます。 これは、もし呼び出された特定の関数が適用するべき照合順序を知っておく必要がないかぎりエラーの条件ではありません。 もし知っておく必要がある場合は、実行時にエラーとなります。

For example, consider this table definition: 例えば、このテーブル定義を考えてみます。

CREATE TABLE test1 (
    a text COLLATE "de_DE",
    b text COLLATE "es_ES",
    ...
);

Then in このとき

SELECT a < 'foo' FROM test1;

the <literal>&lt;</literal> comparison is performed according to <literal>de_DE</literal> rules, because the expression combines an implicitly derived collation with the default collation. But in < の比較はde_DEの規則により実行されます。 というのも式は暗黙的に導出されたデフォルトの照合順序と組み合わせます。しかし、

SELECT a < ('foo' COLLATE "fr_FR") FROM test1;

the comparison is performed using <literal>fr_FR</literal> rules, because the explicit collation derivation overrides the implicit one. Furthermore, given このとき比較は、明示的な照合順序の導出は暗黙の照合順序をオーバーライドするためfr_FR規則が用いられます。 さらに、次の例では

SELECT a < b FROM test1;

the parser cannot determine which collation to apply, since the <structfield>a</structfield> and <structfield>b</structfield> columns have conflicting implicit collations. Since the <literal>&lt;</literal> operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus: パーサはどの照合順序を適用するか決定できません。というのもab列は暗黙の衝突する照合順序を持つためです。 < 演算子がどちらの照合順序を使用するか知る必要があるため、エラーとなります。 このエラーは、どちらかの入力式に明示的な照合順序の指定を付加することで解決できます。 つまり、以下のようになります。

SELECT a < b COLLATE "de_DE" FROM test1;

or equivalently もしくは以下でも同じです。

SELECT a COLLATE "de_DE" < b FROM test1;

On the other hand, the structurally similar case 一方で、以下のように構造的に似たケースとして

SELECT a || b FROM test1;

does not result in an error, because the <literal>||</literal> operator does not care about collations: its result is the same regardless of the collation. これはエラーとなりません。というのも || 演算子は、照合順序には関係がないためです。 この結果は照合順序と関係なく同じになります。

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in もし関数や演算子が照合順序可能なデータ型の結果を出力する場合は、関数に割り当てられた照合順序、もしくは演算子の組み合わされた入力式は、関数もしくは演算子の結果に対しても 適用されると考えられます。よって、以下の例では

SELECT * FROM test1 ORDER BY a || 'foo';

the ordering will be done according to <literal>de_DE</literal> rules. But this query: 順序はde_DE規則に基づき実行されますが、以下の問い合わせでは

SELECT * FROM test1 ORDER BY a || b;

results in an error, because even though the <literal>||</literal> operator doesn't need to know a collation, the <literal>ORDER BY</literal> clause does. As before, the conflict can be resolved with an explicit collation specifier: エラーとなります。というのも || 演算子が照合順序を知る必要がなかったとしても ORDER BY句が照合順序を知る必要があるためです。 以前と同様、この衝突は明示的に照合順序を指定することにより解決できます。

SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";

23.2.2. 照合順序の管理 #

<title>Managing Collations</title>

A collation is an SQL schema object that maps an SQL name to locales provided by libraries installed in the operating system. A collation definition has a <firstterm>provider</firstterm> that specifies which library supplies the locale data. One standard provider name is <literal>libc</literal>, which uses the locales provided by the operating system C library. These are the locales used by most tools provided by the operating system. Another provider is <literal>icu</literal>, which uses the external ICU<indexterm><primary>ICU</primary></indexterm> library. ICU locales can only be used if support for ICU was configured when PostgreSQL was built. 照合順序は、SQL名称を、オペレーティングシステム中にインストールされたライブラリによって提供されるロケールにマッピングするSQLスキーマオブジェクトです。 照合順序の定義には、ロケールデータを提供するライブラリを指定するプロバイダ(provider)が含まれます。 標準プロバイダの一つはlibcで、オペレーティングシステムのCライブラリが提供するロケールを使用します。 オペレーティングシステムが提供するほとんどのツールが、このロケールを使用します。 他のプロバイダとしてはicuがあり、外部のICUライブラリを使います。 ICUロケールは、PostgreSQLがビルドされた際にICUサポートが設定されていた場合にのみ利用可能です。

A collation object provided by <literal>libc</literal> maps to a combination of <symbol>LC_COLLATE</symbol> and <symbol>LC_CTYPE</symbol> settings, as accepted by the <literal>setlocale()</literal> system library call. (As the name would suggest, the main purpose of a collation is to set <symbol>LC_COLLATE</symbol>, which controls the sort order. But it is rarely necessary in practice to have an <symbol>LC_CTYPE</symbol> setting that is different from <symbol>LC_COLLATE</symbol>, so it is more convenient to collect these under one concept than to create another infrastructure for setting <symbol>LC_CTYPE</symbol> per expression.) Also, a <literal>libc</literal> collation is tied to a character set encoding (see <xref linkend="multibyte"/>). The same collation name may exist for different encodings. libcが提供する照合順序は、setlocale()システムライブラリの呼び出しが許可するLC_COLLATELC_CTYPEの組み合わせ設定にマッピングします。 (名称から推測されるように、照合順序の主な目的はソート順序を制御するLC_COLLATEを設定することです。 しかし実際にはLC_CTYPEの設定をLC_COLLATEと異なるようにする必要はほとんどありません。 そのため、式ごとにLC_CTYPEを設定するような別の機構を作成するより、これらの設定を収集する方が、より便利です。) また、libcの照合順序は文字エンコーディングと結びついています(23.3を参照してください)。 同一の照合順序名称が異なるエンコーディングに対して存在しています。

A collation object provided by <literal>icu</literal> maps to a named collator provided by the ICU library. ICU does not support separate <quote>collate</quote> and <quote>ctype</quote> settings, so they are always the same. Also, ICU collations are independent of the encoding, so there is always only one ICU collation of a given name in a database. icuが提供する照合順序オブジェクトは、ICUライブラリが提供する照合順序機能(collator)にマップします。 ICUはcollatectypeを別々に設定する機能を提供しないので、それら常に同じものになります。 また、ICUの照合順序はエンコーディングからは独立しています。 ですから、データベース中のある名前のICU照合順序は、常にただひとつだけです。

23.2.2.1. 標準の照合順序 #

<title>Standard Collations</title>

On all platforms, the following collations are supported: 《機械翻訳》すべてのプラットフォームで、次の照合がサポートされています。

unicode

This SQL standard collation sorts using the Unicode Collation Algorithm with the Default Unicode Collation Element Table. It is available in all encodings. ICU support is required to use this collation, and behavior may change if Postgres is built with a different version of ICU. (This collation has the same behavior as the ICU root locale; see <xref linkend="collation-managing-predefined-icu-und-x-icu"/>.) 《マッチ度[72.195122]》この照合順序は、デフォルトUnicode照合基本テーブルを使用してUnicode照合アルゴリズムで並べ替えます。 すべてのエンコーディングで使用できます。 この照合順序を使用するにはICUサポートが必要です。 (この照合順序は、ICU rootロケールと同じ動作をします。 und-x-icu (undefined用)を参照してください。) 《機械翻訳》このSQL標準照合順序は、Unicode照合順序アルゴリズムとデフォルトUnicode照合順序エレメントテーブルを使用してソートします。 すべてのエンコーディングで使用できます。 この照合順序を使用するにはICUサポートが必要であり、PostgresがICUの別のバージョンで構築されている場合は動作が変更される可能性があります(この照合順序はICUルートロケールと同じ動作をします。 und-x-icu (undefined用)を参照してください。)

ucs_basic

This SQL standard collation sorts using the Unicode code point values rather than natural language order, and only the ASCII letters <quote><literal>A</literal></quote> through <quote><literal>Z</literal></quote> are treated as letters. The behavior is efficient and stable across all versions. Only available for encoding <literal>UTF8</literal>. (This collation has the same behavior as the libc locale specification <literal>C</literal> in <literal>UTF8</literal> encoding.) 《機械翻訳》このSQL標準照合順序では、言語コードポイントではなくUnicodeオーダーの値を使用してソートされ、ASCII文字AからZのみが文字として扱われます。 動作は効率的で、すべてのバージョンにわたって安定(stable)です。 エンコーディングUTF8でのみ使用可能です。 (この照合順序は、UTF8エンコーディングのlibcロケール指定Cと同じ動作をします。)

pg_c_utf8

This collation sorts by Unicode code point values rather than natural language order. For the functions <function>lower</function>, <function>initcap</function>, and <function>upper</function>, it uses Unicode simple case mapping. For pattern matching (including regular expressions), it uses the POSIX Compatible variant of Unicode <ulink url="https://www.unicode.org/reports/tr18/#Compatibility_Properties">Compatibility Properties</ulink>. Behavior is efficient and stable within a <productname>Postgres</productname> major version. This collation is only available for encoding <literal>UTF8</literal>. 《機械翻訳》この照合順序は、自然言語のコードポイントではなく、Unicodeのオーダー値でソートされます。 関数lowerinitcapupperには、Unicodeシンプルケースマッピングを使用します。 パターンマッチ(正規表現を含む)の場合は、POSIX互換のUnicode互換性プロパティを使用します。 行動は効率的であり、安定(stable)メジャーバージョン内のPostgresである。 この照合順序は、エンコーディングUTF8でのみ使用できます。

C (equivalent to POSIX)

The <literal>C</literal> and <literal>POSIX</literal> collations are based on <quote>traditional C</quote> behavior. They sort by byte values rather than natural language order, and only the ASCII letters <quote><literal>A</literal></quote> through <quote><literal>Z</literal></quote> are treated as letters. The behavior is efficient and stable across all versions for a given database encoding, but behavior may vary between different database encodings. 《機械翻訳》CPOSIXの照合は、従来のCの動作に基づいています。 ソート言語のバイトではなくオーダー値で照合され、ASCII文字AからZまでのみが文字として扱われます。 この動作は効率的であり、特定のデータベースエンコーディングのすべてのバージョンで安定(stable)ですが、動作はデータベースのエンコーディングによって異なる場合があります。

default

The <literal>default</literal> collation selects the locale specified at database creation time. 《機械翻訳》デフォルト照合順序は、ロケールの作成時に指定したデータベースを選択します。

Additional collations may be available depending on operating system support. The efficiency and stability of these additional collations depend on the collation provider, the provider version, and the locale. 《機械翻訳》オペレーティングシステムサポートによっては、追加の照合を使用できる場合があります。 これらの追加の照合の効率性と安定度は、照合順序プロバイダ、プロバイダバージョン、およびロケールによって異なります。

23.2.2.2. 定義済みの照合順序 #

<title>Predefined Collations</title>

If the operating system provides support for using multiple locales within a single program (<function>newlocale</function> and related functions), or if support for ICU is configured, then when a database cluster is initialized, <command>initdb</command> populates the system catalog <literal>pg_collation</literal> with collations based on all the locales it finds in the operating system at the time. オペレーティングシステムが単一のプログラム内(newlocaleや関連する関数)で複数のロケールを使用することをサポートしているか、ICUサポートが組み込み済みの場合、データベースクラスタが初期化されるとinitdbは、オペレーティングシステム上で見つけた全てのロケールに基づく照合順序をシステムカタログのpg_collationに書き込みます。

To inspect the currently available locales, use the query <literal>SELECT * FROM pg_collation</literal>, or the command <command>\dOS+</command> in <application>psql</application>. 現在利用可能なロケールを調べるには、SELECT * FROM pg_collationという問合せを使うか、psql内で\dOS+コマンドを使用します。

23.2.2.2.1. libc照合順序 #
<title>libc Collations</title>

For example, the operating system might provide a locale named <literal>de_DE.utf8</literal>. <command>initdb</command> would then create a collation named <literal>de_DE.utf8</literal> for encoding <literal>UTF8</literal> that has both <symbol>LC_COLLATE</symbol> and <symbol>LC_CTYPE</symbol> set to <literal>de_DE.utf8</literal>. It will also create a collation with the <literal>.utf8</literal> tag stripped off the name. So you could also use the collation under the name <literal>de_DE</literal>, which is less cumbersome to write and makes the name less encoding-dependent. Note that, nevertheless, the initial set of collation names is platform-dependent. 例えば、オペレーティングシステムがde_DE.utf8という名称のロケールを提供するとします。 initdbは、de_DE.utf8に設定されたLC_COLLATELC_CTYPEの両方を持つUTF8エンコーディングのde_DE.utf8という名称の照合順序を作成します。 同時に照合順序の名称から.utf8タグを削除した照合順序も作成します。 そのため、de_DEという名前の照合を使用することもできます。 これは手間を省き、名称がエンコーディングに依存しにくいようになります。 それにもかかわらず、照合順序名称の初期値はプラットフォーム依存となることに気をつけてください。

The default set of collations provided by <literal>libc</literal> map directly to the locales installed in the operating system, which can be listed using the command <literal>locale -a</literal>. In case a <literal>libc</literal> collation is needed that has different values for <symbol>LC_COLLATE</symbol> and <symbol>LC_CTYPE</symbol>, or if new locales are installed in the operating system after the database system was initialized, then a new collation may be created using the <xref linkend="sql-createcollation"/> command. New operating system locales can also be imported en masse using the <link linkend="functions-admin-collation"><function>pg_import_system_collations()</function></link> function. libcが提供するデフォルトの照合順序の集合は、直接オペレーティングシステム内にインストールされたロケールにマップされ、コマンドlocale -aで参照できます。 LC_COLLATELC_CTYPEで違う値を持つlibc照合順序が必要な場合、あるいはデータベースシステムが初期化された後に新しいロケールがインストールされた場合は、新しい照合順序をCREATE COLLATIONコマンドで作成できます。 また、新しいオペレーティングシステムロケールは、pg_import_system_collations()関数でインポートできます。

Within any particular database, only collations that use that database's encoding are of interest. Other entries in <literal>pg_collation</literal> are ignored. Thus, a stripped collation name such as <literal>de_DE</literal> can be considered unique within a given database even though it would not be unique globally. Use of the stripped collation names is recommended, since it will make one fewer thing you need to change if you decide to change to another database encoding. Note however that the <literal>default</literal>, <literal>C</literal>, and <literal>POSIX</literal> collations can be used regardless of the database encoding. どのようなデータベース内でも、データベースのエンコーディングを使用している照合順序のみが興味の対象となります。 pg_collation内の他のエントリは無視されます。 よってde_DEといったようなエンコーディング名が省かれた照合順序は、一般的には一意でなくてもデータベース内では一意であるとみなされます。 エンコーディング名が省かれた照合順序を使用することを推奨します。 というのも、データベースのエンコーディングを変更するときに、変えなければならないものを1つ減らせるからです。 しかし、defaultCそしてPOSIX照合順序は、データベースのエンコーディングに関係なく使用可能であることに注意してください。

<productname>PostgreSQL</productname> considers distinct collation objects to be incompatible even when they have identical properties. Thus for example, PostgreSQLは、異なる照合順序オブジェクトは、それらが同じプロパティを持っていても互換性がないものとみなします。 例えば、

SELECT a COLLATE "C" < b COLLATE "POSIX" FROM test1;

will draw an error even though the <literal>C</literal> and <literal>POSIX</literal> collations have identical behaviors. Mixing stripped and non-stripped collation names is therefore not recommended. は、CPOSIX照合順序が同じ動作であってもエラーとなります。 よってエンコーディング名が省かれた照合順序を混ぜて使用することは推奨されません。

23.2.2.2.2. ICU照合順序 #
<title>ICU Collations</title>

With ICU, it is not sensible to enumerate all possible locale names. ICU uses a particular naming system for locales, but there are many more ways to name a locale than there are actually distinct locales. <command>initdb</command> uses the ICU APIs to extract a set of distinct locales to populate the initial set of collations. Collations provided by ICU are created in the SQL environment with names in BCP 47 language tag format, with a <quote>private use</quote> extension <literal>-x-icu</literal> appended, to distinguish them from libc locales. ICUにおいては、すべての可能なロケール名を列挙するのは賢明ではありません。 ICUはロケールの固有の名前付けシステムを使っています。 しかし、実際の個別のロケール名以上の名前を付ける多くの方法があります。 initdbはICUのAPIを使い、照合順序の初期集合を入力するための 個別のロケールの集合を取り出します。 ICUが提供する照合順序は、libcロケールと区別するために、SQL環境において、私的利用拡張-x-icuを追加したBCP 47言語タグ形式の名前で作成されます。

Here are some example collations that might be created: 以下は作成されるかもしれない照合順序の例です。

de-x-icu #
<para>German collation, default variant</para>

ドイツ語照合順序、デフォルトの異型

de-AT-x-icu #
<para>German collation for Austria, default variant</para>

オーストリアのドイツ語照合順序、デフォルトの異型

(There are also, say, <literal>de-DE-x-icu</literal> or <literal>de-CH-x-icu</literal>, but as of this writing, they are equivalent to <literal>de-x-icu</literal>.) (他に、de-DE-x-icuあるいはde-CH-x-icuというのがあります。 しかし、本稿執筆時点では、それらはde-x-icuと同じです。)

und-x-icu (undefined用) #

ICU <quote>root</quote> collation. Use this to get a reasonable language-agnostic sort order. ICUroot照合順序。 言語に依存しない適当なソート順を得るために使用してください。

Some (less frequently used) encodings are not supported by ICU. When the database encoding is one of these, ICU collation entries in <literal>pg_collation</literal> are ignored. Attempting to use one will draw an error along the lines of <quote>collation "de-x-icu" for encoding "WIN874" does not exist</quote>. ある種の(利用頻度が低い)エンコーディングをICUはサポートしません。 データベースエンコーディングがこのようなものであった場合、pg_collation中のICU照合順序は無視されます。 このようなものを使おうとすると、collation "de-x-icu" for encoding "WIN874" does not existというメッセージを伴ったエラーが発生します。

23.2.2.3. 新しい照合順序オブジェクトの作成 #

<title>Creating New Collation Objects</title>

If the standard and predefined collations are not sufficient, users can create their own collation objects using the SQL command <xref linkend="sql-createcollation"/>. 標準の定義済み照合順序が十分でない場合は、ユーザはSQLコマンドCREATE COLLATIONで照合順序オブジェクトを作成できます。

The standard and predefined collations are in the schema <literal>pg_catalog</literal>, like all predefined objects. User-defined collations should be created in user schemas. This also ensures that they are saved by <command>pg_dump</command>. すべての定義済みオブジェクト同様、標準の定義済み照合順序はpg_catalogスキーマにあります。 ユーザ定義の照合順序はユーザのスキーマに作成するべきです。 これはまた、pg_dumpの保存対象になることを確実にします。

23.2.2.3.1. libc照合順序 #
<title>libc Collations</title>

New libc collations can be created like this: 以下のようにして新しいlibc照合順序を作成できます。

CREATE COLLATION german (provider = libc, locale = 'de_DE');

The exact values that are acceptable for the <literal>locale</literal> clause in this command depend on the operating system. On Unix-like systems, the command <literal>locale -a</literal> will show a list. コマンド中のlocale句に使用できる正確な値は、オペレーティングシステムに依存します。 Unix系のシステムでは、locale -aコマンドでこのリストを表示できるでしょう。

Since the predefined libc collations already include all collations defined in the operating system when the database instance is initialized, it is not often necessary to manually create new ones. Reasons might be if a different naming system is desired (in which case see also <xref linkend="collation-copy"/>) or if the operating system has been upgraded to provide new locale definitions (in which case see also <link linkend="functions-admin-collation"><function>pg_import_system_collations()</function></link>). 定義済みのlibc照合順序は、データベースインスタンスが初期化された際に、オペレーティングシステムで定義されたすべての照合順序をすでに含んでいるので、新しいものを手動で作る必要はあまりないでしょう。 そうしたことをする理由があるとすれば、異なる命名規則が必要である(この場合は、23.2.2.3.3も参照してください)、あるいはオペレーティングシステムが更新されて、新しいロケールの定義が提供されるようになった場合です。(この場合はpg_import_system_collations()も参照してください。)

23.2.2.3.2. ICU照合順序 #
<title>ICU Collations</title>

ICU collations can be created like: ICU照合順序は次のように作成できます。

CREATE COLLATION german (provider = icu, locale = 'de-DE');

ICU locales are specified as a BCP 47 <link linkend="icu-language-tag">Language Tag</link>, but can also accept most libc-style locale names. If possible, libc-style locale names are transformed into language tags. ICUロケールはBCP 47言語タグとして指定されますが、ほとんどのlibcスタイルのロケール名も受け入れます。 可能な場合、libcスタイルのロケール名は言語タグに変換されます。

New ICU collations can customize collation behavior extensively by including collation attributes in the language tag. See <xref linkend="icu-custom-collations"/> for details and examples. 新しいカスタマイズICU照合順序では、照合順序タグに照合順序属性を含めることで、言語の動作を広範囲にICU化できます。 詳細と例については、23.2.3を参照してください。

23.2.2.3.3. 照合順序の複製 #
<title>Copying Collations</title>

The command <xref linkend="sql-createcollation"/> can also be used to create a new collation from an existing collation, which can be useful to be able to use operating-system-independent collation names in applications, create compatibility names, or use an ICU-provided collation under a more readable name. For example: コマンドCREATE COLLATIONは、既存の照合順序から新しい照合順序を作る際にも利用できます。 これは、オペレーティングシステムから独立した照合順序名をアプリケーションで使用可能にしたり、互換性のある名称を作成したり、ICUが提供する照合順序を、よりわかりやすい名称で利用するのに役立ちます。 例を示します。

CREATE COLLATION german FROM "de_DE";
CREATE COLLATION french FROM "fr-x-icu";

23.2.2.4. 非決定論的な照合順序 #

<title>Nondeterministic Collations</title>

A collation is either <firstterm>deterministic</firstterm> or <firstterm>nondeterministic</firstterm>. A deterministic collation uses deterministic comparisons, which means that it considers strings to be equal only if they consist of the same byte sequence. Nondeterministic comparison may determine strings to be equal even if they consist of different bytes. Typical situations include case-insensitive comparison, accent-insensitive comparison, as well as comparison of strings in different Unicode normal forms. It is up to the collation provider to actually implement such insensitive comparisons; the deterministic flag only determines whether ties are to be broken using bytewise comparison. See also <ulink url="https://www.unicode.org/reports/tr10">Unicode Technical Standard 10</ulink> for more information on the terminology. 照合順序は決定論的もしくは非決定論的のどちらかです。 決定論的な照合順序は決定論的な比較を使用します。 つまり、同じバイト列で構成される場合に限り等しい文字列とみなします。 非決定論的な比較は、異なるバイト値で構成される文字列の場合でさえ文字列が等しいと判定するかもしれません。 一般的な状況では、大文字小文字を区別しない比較、アクセントを区別しない比較および異なるUnicode正規化形式による文字列の比較が含まれます。 このような区別しない比較を実際に実装するかは照合順序のプロバイダ次第です。 deterministicフラグはバイト単位の比較を用いて分解されるかどうかのみを決定します。 用語の詳細については、Unicode Technical Standard 10を参照してください。

To create a nondeterministic collation, specify the property <literal>deterministic = false</literal> to <command>CREATE COLLATION</command>, for example: 非決定論的な照合順序を作るためにはCREATE COLLATIONdeterministic = falseプロパティを指定します。 以下に例を示します。

CREATE COLLATION ndcoll (provider = icu, locale = 'und', deterministic = false);

This example would use the standard Unicode collation in a nondeterministic way. In particular, this would allow strings in different normal forms to be compared correctly. More interesting examples make use of the ICU customization facilities explained above. For example: この例では非決定論的な方法で標準のUnicode照合順序を使えます。 具体的には、これは異なる正規形の文字列を正しく比較できるでしょう。 より興味深い例は上述したICUカスタマイズ機能を用いた場合です。 以下に例を示します。

CREATE COLLATION case_insensitive (provider = icu, locale = 'und-u-ks-level2', deterministic = false);
CREATE COLLATION ignore_accents (provider = icu, locale = 'und-u-ks-level1-kc-true', deterministic = false);

All standard and predefined collations are deterministic, all user-defined collations are deterministic by default. While nondeterministic collations give a more <quote>correct</quote> behavior, especially when considering the full power of Unicode and its many special cases, they also have some drawbacks. Foremost, their use leads to a performance penalty. Note, in particular, that B-tree cannot use deduplication with indexes that use a nondeterministic collation. Also, certain operations are not possible with nondeterministic collations, such as pattern matching operations. Therefore, they should be used only in cases where they are specifically wanted. すべての標準および事前に定義された照合順序は決定論的であり、すべてのユーザ定義の照合順序はデフォルトで決定論的です。 特にUnicodeの全機能およびその特別な場合を考えた際、非決定論的な照合順序はより多くの正しい振る舞いを与えると同時に、いくつかの欠点もあります。 第一にそれらを使用するとパフォーマンスが低下します。 B-treeは非決定的照合順序を使用したインデックスでは重複排除には使用できないことに特に注意してください。 また、パターンマッチング操作などで非決定論的な照合順序による操作ができないことも避けられません。 したがって、これらは明確に必要とされる場合のみに使用されるべきです。

ヒント

To deal with text in different Unicode normalization forms, it is also an option to use the functions/expressions <function>normalize</function> and <literal>is normalized</literal> to preprocess or check the strings, instead of using nondeterministic collations. There are different trade-offs for each approach. 異なるUnicode正規化形式のテキストを処理する場合、非決定論的な照合を使用する代わりにnormalizeおよびis normalized関数もしくは式を使用して文字列の前処理もしくはチェックをするオプションもあります。 それぞれのアプローチで異なるトレードオフがあります。

23.2.3. ICU照合順序カスタム #

<title>ICU Custom Collations</title>

ICU allows extensive control over collation behavior by defining new collations with collation settings as a part of the language tag. These settings can modify the collation order to suit a variety of needs. For instance: ICUは、言語タグの一部として照合順序設定を持つ新しい照合順序を定義することで、照合順序の動作を広範囲に制御することができます。 これらの設定は、さまざまなニーズに合わせて照合順序順序を変更できます。 インスタンスの場合:

-- ignore differences in accents and case
CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1');
SELECT 'Å' = 'A' COLLATE ignore_accent_case; -- true
SELECT 'z' = 'Z' COLLATE ignore_accent_case; -- true

-- upper case letters sort before lower case.
CREATE COLLATION upper_first (provider = icu, locale = 'und-u-kf-upper');
SELECT 'B' < 'b' COLLATE upper_first; -- true

-- treat digits numerically and ignore punctuation
CREATE COLLATION num_ignore_punct (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-kn');
SELECT 'id-45' < 'id-123' COLLATE num_ignore_punct; -- true
SELECT 'w;x*y-z' = 'wxyz' COLLATE num_ignore_punct; -- true

Many of the available options are described in <xref linkend="icu-collation-settings"/>, or see <xref linkend="icu-external-references"/> for more details. 利用可能なオプションの多くは23.2.3.2で説明されています。 詳細は23.2.3.5を参照してください。

23.2.3.1. ICU比較レベル #

<title>ICU Comparison Levels</title>

Comparison of two strings (collation) in ICU is determined by a multi-level process, where textual features are grouped into "levels". Treatment of each level is controlled by the <link linkend="icu-collation-settings-table">collation settings</link>. Higher levels correspond to finer textual features. ICUでの2つの文字列の比較(照合)は、テキストの特徴が「レベル」にグループ化される多段階プロセスによって決定されます。 各レベルの処理は、照合設定によって制御されます。 高いレベルは、より細かいテキストの特徴に対応します。

<xref linkend="icu-collation-levels"/> shows which textual feature differences are considered significant when determining equality at the given level. The Unicode character <literal>U+2063</literal> is an invisible separator, and as seen in the table, is ignored for at all levels of comparison less than <literal>identic</literal>. 表 23.1は、指定されたレベルで等しいかどうかを決定する際に重要とされるテキスト特徴の違いを示しています。 Unicode文字U+2063は不可視のセパレータであり、表に示されているように、identic未満のすべての比較レベルで無視されます。

表23.1 ICU照合順序レベル

<title>ICU Collation Levels</title>
レベル説明'f' = 'f''ab' = U&'a\2063b''x-y' = 'x_y''g' = 'G''n' = 'ñ''y' = 'z'
level1基本文字truetruetruetruetruefalse
level2アクセントtruetruetruetruefalsefalse
level3大文字小文字/異型truetruetruefalsefalsefalse
level4Punctuation[a]truetruefalsefalsefalsefalse
identicすべてtruefalsefalsefalsefalsefalse

[a] only with ka-shifted; see 表 23.2


At every level, even with full normalization off, basic normalization is performed. For example, <literal>'á'</literal> may be composed of the code points <literal>U&amp;'\0061\0301'</literal> or the single code point <literal>U&amp;'\00E1'</literal>, and those sequences will be considered equal even at the <literal>identic</literal> level. To treat any difference in code point representation as distinct, use a collation created with <symbol>deterministic</symbol> set to <literal>true</literal>. すべてのレベルで、完全正規化が無効であっても基本正規化は行われます。 例の場合、'á'はコードポイントU&'\0061\0301'または単一コードポイントU&'\00E1'で構成され、これらのシーケンスはidenticレベルでも等しいとみなされます。 コードポイント表現形式内の差を個別として扱うには、deterministictrueに設定して作成された照合順序を使用します。

23.2.3.1.1. 照合順序レベルの例 #
<title>Collation Level Examples</title>
CREATE COLLATION level3 (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-level3');
CREATE COLLATION level4 (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-level4');
CREATE COLLATION identic (provider = icu, deterministic = false, locale = 'und-u-ka-shifted-ks-identic');

-- invisible separator ignored at all levels except identic
SELECT 'ab' = U&'a\2063b' COLLATE level4; -- true
SELECT 'ab' = U&'a\2063b' COLLATE identic; -- false

-- punctuation ignored at level3 but not at level 4
SELECT 'x-y' = 'x_y' COLLATE level3; -- true
SELECT 'x-y' = 'x_y' COLLATE level4; -- false

23.2.3.2. ICUロケールの照合順序設定 #

<title>Collation Settings for an ICU Locale</title>

<xref linkend="icu-collation-settings-table"/> shows the available collation settings, which can be used as part of a language tag to customize a collation. 表 23.2には、利用可能な照合順序設定が表示されます。 これらは言語タグの一部として使用して照合順序をカスタマイズすることができます。

表23.2 ICU照合順序設定

<title>ICU Collation Settings</title>
キーデフォルト説明
coemoji, phonebk, standard, ...standard Collation type. See <xref linkend="icu-external-references"/> for additional options and details. 照合順序タイプ。追加のオプションと詳細については23.2.3.5を参照してください。
kanoignore, shiftednoignore If set to <literal>shifted</literal>, causes some characters (e.g. punctuation or space) to be ignored in comparison. Key <literal>ks</literal> must be set to <literal>level3</literal> or lower to take effect. Set key <literal>kv</literal> to control which character classes are ignored. shiftedに設定されている場合、いくつかの文字(例:句読点やスペース)が比較で無視されるようになります。 効果を発揮するには、キーkslevel3以下に設定する必要があります。 どの文字クラスが無視されるかを制御するためにキーkvを設定します。
kbtrue, falsefalse Backwards comparison for the level 2 differences. For example, locale <literal>und-u-kb</literal> sorts <literal>'àe'</literal> before <literal>'aé'</literal>. レベル2の差異の逆比較。 例えば、ロケールund-u-kb'àe''aé'よりも前に並べます。
kctrue, falsefalse

Separates case into a "level 2.5" that falls between accents and other level 3 features. 大文字小文字をアクセントと他のレベル3の特徴の間に「レベル2.5」として分離します。

If set to <literal>true</literal> and <literal>ks</literal> is set to <literal>level1</literal>, will ignore accents but take case into account. trueに設定されており、kslevel1に設定されている場合、アクセントを無視しますが、大文字小文字を考慮します。

kf upper, lower, false false If set to <literal>upper</literal>, upper case sorts before lower case. If set to <literal>lower</literal>, lower case sorts before upper case. If set to <literal>false</literal>, the sort depends on the rules of the locale. upperに設定されている場合、大文字が小文字よりも前に並べられます。 lowerに設定されている場合、小文字が大文字よりも前に並べられます。 falseに設定されている場合、並べ替えはロケールの規則に依存します。
kntrue, falsefalse If set to <literal>true</literal>, numbers within a string are treated as a single numeric value rather than a sequence of digits. For example, <literal>'id-45'</literal> sorts before <literal>'id-123'</literal>. trueに設定されている場合、文字列内の数字は、数字のシーケンスではなく単一の数値として扱われます。 例えば、'id-45''id-123'よりも前に並べられます。
kktrue, falsefalse

Enable full normalization; may affect performance. Basic normalization is performed even when set to <literal>false</literal>. Locales for languages that require full normalization typically enable it by default. 完全正規化を有効にします。 パフォーマンスに影響する場合があります。 基本正規化は、falseに設定されている場合でも実行されます。 完全正規化を必要とする言語のロケールでは、通常、デフォルトによって有効にされます。

Full normalization is important in some cases, such as when multiple accents are applied to a single character. For example, the code point sequences <literal>U&amp;'\0065\0323\0302'</literal> and <literal>U&amp;'\0065\0302\0323'</literal> represent an <literal>e</literal> with circumflex and dot-below accents applied in different orders. With full normalization on, these code point sequences are treated as equal; otherwise they are unequal. 複数のアクセントが単一の文字に適用される場合など、完全正規化が重要な場合があります。 例えば、コードポイントシーケンスU&'\0065\0323\0302'U&'\0065\0302\0323'は、異なる順序で適用されたサーカムフレックスと下ドットのアクセントを持つeを表します。 完全正規化が有効の場合、これらのコードポイントシーケンスは等しいものとして扱われます。 それ以外の場合は等しくありません。

kr space, punct, symbol, currency, digit, script-id  

Set to one or more of the valid values, or any BCP 47 <replaceable>script-id</replaceable>, e.g. <literal>latn</literal> ("Latin") or <literal>grek</literal> ("Greek"). Multiple values are separated by "<literal>-</literal>". 1つ以上の有効な値、または任意のBCP 47script-idに設定します。 たとえば、latn("ラテン")またはgrek("ギリシャ")です。 複数の値は"-"で区切ります。

Redefines the ordering of classes of characters; those characters belonging to a class earlier in the list sort before characters belonging to a class later in the list. For instance, the value <literal>digit-currency-space</literal> (as part of a language tag like <literal>und-u-kr-digit-currency-space</literal>) sorts punctuation before digits and spaces. 文字クラスの順序を再定義します。 リストの後の文字クラスに属する文字は、リストの後の文字クラスに属する文字よりも前に並べられます。 たとえば、値digit-currency-space(言語タグの一部としてund-u-kr-digit-currency-space)は、句読点を数字とスペースの前に並べます。

kslevel1, level2, level3, level4, identiclevel3 Sensitivity (or "strength") when determining equality, with <literal>level1</literal> the least sensitive to differences and <literal>identic</literal> the most sensitive to differences. See <xref linkend="icu-collation-levels"/> for details. 等価性を決定する際の感度(または「強度」)で、level1は差異に対して最も感度が低く、identicは差異に対して最も感度が高いです。 詳細は表 23.1を参照してください。
kv space, punct, symbol, currency punct Classes of characters ignored during comparison at level 3. Setting to a later value includes earlier values; e.g. <literal>symbol</literal> also includes <literal>punct</literal> and <literal>space</literal> in the characters to be ignored. Key <literal>ka</literal> must be set to <literal>shifted</literal> and key <literal>ks</literal> must be set to <literal>level3</literal> or lower to take effect. レベル3での比較中に無視される文字クラス。 後の値に設定すると、前の値も含まれます。 たとえば、symbolpunctおよびspaceも含みます。 無視される文字を含む文字にキーkashiftedに設定し、キーkslevel3以下に設定する必要があります。

Defaults may depend on locale. The above table is not meant to be complete. See <xref linkend="icu-external-references"/> for additional options and details. デフォルトはロケールによって異なります。 上記のテーブルは完全なものではありません。 追加のオプションと詳細については23.2.3.5を参照してください。

注記

For many collation settings, you must create the collation with <option>deterministic</option> set to <literal>false</literal> for the setting to have the desired effect (see <xref linkend="collation-nondeterministic"/>). Additionally, some settings only take effect when the key <literal>ka</literal> is set to <literal>shifted</literal> (see <xref linkend="icu-collation-settings-table"/>). 多くの照合順序設定では、目的の効果を得るために、deterministicfalseに設定した照合順序を作成する必要があります(23.2.2.4を参照)。 また、キーkashiftedに設定されている場合にのみ有効になる設定もあります(表 23.2を参照)。

23.2.3.3. 照合順序設定の例 #

<title>Collation Settings Examples</title>
CREATE COLLATION "de-u-co-phonebk-x-icu" (provider = icu, locale = 'de-u-co-phonebk'); #
<para>German collation with phone book collation type</para>

電話帳照合順形式を伴うドイツ語の照合順序

CREATE COLLATION "und-u-co-emoji-x-icu" (provider = icu, locale = 'und-u-co-emoji'); #

Root collation with Emoji collation type, per Unicode Technical Standard #51 絵文字照合順序型を伴うroot照合順序。Unicode Technical Standard #51による。

CREATE COLLATION latinlast (provider = icu, locale = 'en-u-kr-grek-latn'); #

Sort Greek letters before Latin ones. (The default is Latin before Greek.) ラテン文字の前にギリシャ文字が来るように並べます。(デフォルトではギリシャ文字の前にラテン文字が来ます。)

CREATE COLLATION upperfirst (provider = icu, locale = 'en-u-kf-upper'); #

Sort upper-case letters before lower-case letters. (The default is lower-case letters first.) 小文字の前に大文字が来るように並べます。(デフォルトでは最初に小文字が来ます。)

CREATE COLLATION special (provider = icu, locale = 'en-u-kf-upper-kr-grek-latn'); #

Combines both of the above options. 上記のオプションを組み合わせます。

23.2.3.4. ICU適合化規則 #

<title>ICU Tailoring Rules</title>

If the options provided by the collation settings shown above are not sufficient, the order of collation elements can be changed with tailoring rules, whose syntax is detailed at <ulink url="https://unicode-org.github.io/icu/userguide/collation/customization/"></ulink>. 上記のオプション設定によって提供される照合順序が十分でない場合は、照合順序要素のオーダーを適合化規則を使用して変更できます。 適合化規則の構文はで詳しく説明されています。

This small example creates a collation based on the root locale with a tailoring rule: この小さな例は、rootロケールをベースにした照合順序を作成し、ルールを調整します。

CREATE COLLATION custom (provider = icu, locale = 'und', rules = '&V << w <<< W');

With this rule, the letter <quote>W</quote> is sorted after <quote>V</quote>, but is treated as a secondary difference similar to an accent. Rules like this are contained in the locale definitions of some languages. (Of course, if a locale definition already contains the desired rules, then they don't need to be specified again explicitly.) このルールでは、文字WVの後にソートされますが、アクセントと同様に二次的な差として扱われます。 このようなルールは、一部の言語のロケール定義に含まれています。 (もちろん、ロケール定義がすでに目的のルールを包含している場合は、明示的に再指定する必要はありません。)

Here is a more complex example. The following statement sets up a collation named <literal>ebcdic</literal> with rules to sort US-ASCII characters in the order of the EBCDIC encoding. ここに、より複雑な例があります。 次のステートメントは、EBCDIC記名的のオーダーにUS-ASCII文字をソートするためのルールを使用して、照合順序エンコーディングebcdicを設定します。

CREATE COLLATION ebcdic (provider = icu, locale = 'und',
rules = $$
& ' ' < '.' < '<' < '(' < '+' < \|
< '&' < '!' < '$' < '*' < ')' < ';'
< '-' < '/' < ',' < '%' < '_' < '>' < '?'
< '`' < ':' < '#' < '@' < \' < '=' < '"'
<*a-r < '~' <*s-z < '^' < '[' < ']'
< '{' <*A-I < '}' <*J-R < '\' <*S-Z <*0-9
$$);

SELECT c
FROM (VALUES ('a'), ('b'), ('A'), ('B'), ('1'), ('2'), ('!'), ('^')) AS x(c)
ORDER BY c COLLATE ebcdic;
 c
---
 !
 a
 b
 ^
 A
 B
 1
 2

23.2.3.5. ICUの外部参照 #

<title>External References for ICU</title>

This section (<xref linkend="icu-custom-collations"/>) is only a brief overview of ICU behavior and language tags. Refer to the following documents for technical details, additional options, and new behavior: この節(23.2.3)は、概要の動作と言語タグの簡単なオプションです。 技術的な詳細、追加のICU、および新しい動作については、次のドキュメントを参照してください。