説明

<command>CREATE DOMAIN</command> creates a new domain. A domain is essentially a data type with optional constraints (restrictions on the allowed set of values). The user who defines a domain becomes its owner. CREATE DOMAINは新しいドメインを作成します。 ドメインとは本質的には、特別な制約（使用可能な値集合に対する制限）を持ったデータ型です。 ドメインを定義したユーザが、その所有者となります。

If a schema name is given (for example, <literal>CREATE DOMAIN myschema.mydomain ...</literal>) then the domain is created in the specified schema. Otherwise it is created in the current schema. The domain name must be unique among the types and domains existing in its schema. スキーマ名が付けられている場合（例えば、CREATE DOMAIN myschema.mydomain ...）、ドメインは指定されたスキーマに作成されます。 スキーマ名が付けられていなければ、そのドメインは現在のスキーマに作成されます。 ドメイン名は、そのスキーマ内に存在するデータ型およびドメインの間で、一意である必要があります。

Domains are useful for abstracting common constraints on fields into a single location for maintenance. For example, several tables might contain email address columns, all requiring the same CHECK constraint to verify the address syntax. Define a domain rather than setting up each table's constraint individually. ドメインを使用すると、共通な制約を1箇所に抽象化でき、メンテナンスに便利です。 たとえば、E-mailアドレスを格納する列が複数のテーブルで使用されていて、アドレス構文の検証のためすべてが同一のCHECK制約を必要としているような場合です。 このような場合、各テーブルに個別に制約を設定するよりも、ドメインを定義してください。

To be able to create a domain, you must have <literal>USAGE</literal> privilege on the underlying type. ドメインを作成するためには、基となる型に対するUSAGEを持たなければなりません。

パラメータ

注釈

Domain constraints, particularly <literal>NOT NULL</literal>, are checked when converting a value to the domain type. It is possible for a column that is nominally of the domain type to read as null despite there being such a constraint. For example, this can happen in an outer-join query, if the domain column is on the nullable side of the outer join. A more subtle example is ドメイン制約、特にNOT NULLは、値がドメイン型に変換されるときに検査されます。 通常はドメイン型である列が、NOT NULLの制約にも関わらずNULLとして読み出される場合もあり得ます。 例えば、外部結合の問い合わせにおいて、ドメインの列が外部結合のNULLになる側にあるときに、これが起こり得ます。 より微妙な例は以下です。

INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE false));

The empty scalar sub-SELECT will produce a null value that is considered to be of the domain type, so no further constraint checking is applied to it, and the insertion will succeed. 空でスカラーの副問い合わせにより、ドメイン型であると見なされるNULL値が生成されます。 そのため、制約についてこれ以上の検証は行われず、挿入は成功します。

It is very difficult to avoid such problems, because of SQL's general assumption that a null value is a valid value of every data type. Best practice therefore is to design a domain's constraints so that a null value is allowed, and then to apply column <literal>NOT NULL</literal> constraints to columns of the domain type as needed, rather than directly to the domain type. SQLではNULL値はすべてのデータ型で有効な値であると想定されているため、このような問題を回避するのは非常に難しいことです。 したがって、最善の方法は、NOT NULL制約をドメイン型に直接適用するのではなく、NULL値が許されるようにドメインの制約を設計し、その上で、列のNOT NULL制約を、必要に応じて、ドメイン型の列に適用することです。

<productname>PostgreSQL</productname> assumes that <literal>CHECK</literal> constraints' conditions are immutable, that is, they will always give the same result for the same input value. This assumption is what justifies examining <literal>CHECK</literal> constraints only when a value is first converted to be of a domain type, and not at other times. (This is essentially the same as the treatment of table <literal>CHECK</literal> constraints, as described in <xref linkend="ddl-constraints-check-constraints"/>.) PostgreSQLはCHECK制約の条件はimmutableである、すなわち同じ入力値に対しては必ず同じ結果を与えると仮定します。 この仮定は、値が初めてドメイン型に変換された時にのみCHECK制約を確認し、それ以外では確認しないことを正当化するものです。 (これは、5.4.1で述べているテーブルのCHECK制約の扱いと本質的に同じです。)

An example of a common way to break this assumption is to reference a user-defined function in a <literal>CHECK</literal> expression, and then change the behavior of that function. <productname>PostgreSQL</productname> does not disallow that, but it will not notice if there are stored values of the domain type that now violate the <literal>CHECK</literal> constraint. That would cause a subsequent database dump and restore to fail. The recommended way to handle such a change is to drop the constraint (using <command>ALTER DOMAIN</command>), adjust the function definition, and re-add the constraint, thereby rechecking it against stored data. この仮定を破るよくある例は、CHECK式内でユーザ定義関数を参照しており、後でその関数の振舞いを変更することです。 PostgreSQLはそれを拒否しませんが、そのドメイン型の格納された値でCHECK制約に今や違反するものがあることには気付かないでしょう。 これは、その後のデータベースのダンプとリストアが失敗する原因になるかもしれません。 そのような変更を扱うお勧めの方法は、(ALTER DOMAINを使って)制約を削除し、関数の定義を調整し、その制約を再び追加することです。それにより格納されたデータに対して再確認が行われます。

It's also good practice to ensure that domain <literal>CHECK</literal> expressions will not throw errors. ドメインCHECK式がエラーを発生しないのを確実にすることもお勧めです。

例

This example creates the <type>us_postal_code</type> data type and then uses the type in a table definition. A regular expression test is used to verify that the value looks like a valid US postal code: この例では、データ型us_postal_codeを作成し、その型をテーブル定義の中で使用します。 データが有効なUS郵便番号であるかどうかを検証するために正規表現検査が使用されます。

CREATE DOMAIN us_postal_code AS TEXT
CHECK(
   VALUE ~ '^\d{5}$'
OR VALUE ~ '^\d{5}-\d{4}$'
);

CREATE TABLE us_snail_addy (
  address_id SERIAL PRIMARY KEY,
  street1 TEXT NOT NULL,
  street2 TEXT,
  street3 TEXT,
  city TEXT NOT NULL,
  postal us_postal_code NOT NULL
);

互換性

The command <command>CREATE DOMAIN</command> conforms to the SQL standard. CREATE DOMAINコマンドは標準SQLに準拠しています。

関連項目