If specified, the table is created as a temporary table. Temporary tables are automatically dropped at the end of a session, or optionally at the end of the current transaction (see <literal>ON COMMIT</literal> below). The default search_path includes the temporary schema first and so identically named existing permanent tables are not chosen for new plans while the temporary table exists, unless they are referenced with schema-qualified names. Any indexes created on a temporary table are automatically temporary as well. このパラメータが指定された場合、テーブルは一時テーブルとして作成されます。 一時テーブルは、そのセッションの終わり、場合によっては、現在のトランザクションの終わり（後述のON COMMITを参照）に自動的に削除されます。 デフォルトのsearch_pathは一時スキーマを最初に含んでいますので、同じ名前を持つ既存の永続テーブルは、スキーマ修飾名で参照されていない限り、一時テーブルが存在する間は非可視になります。 一時テーブルに作られるインデックスも、全て自動的に一時的なものとなります。

The <link linkend="autovacuum">autovacuum daemon</link> cannot access and therefore cannot vacuum or analyze temporary tables. For this reason, appropriate vacuum and analyze operations should be performed via session SQL commands. For example, if a temporary table is going to be used in complex queries, it is wise to run <command>ANALYZE</command> on the temporary table after it is populated. 自動バキュームデーモンは一時テーブルにアクセスできないため、一時テーブルのバキュームや解析を行うことはできません。 このためセッションのSQLコマンドを用いて適切なバキュームと解析を実行しなければなりません。 例えば、一時テーブルが複雑な問い合わせで使用される場合、一時テーブルにデータを投入した後にそれに対しANALYZEを実行することを勧めます。

Optionally, <literal>GLOBAL</literal> or <literal>LOCAL</literal> can be written before <literal>TEMPORARY</literal> or <literal>TEMP</literal>. This presently makes no difference in <productname>PostgreSQL</productname> and is deprecated; see <xref linkend="sql-createtable-compatibility"/> below. オプションで、GLOBALまたはLOCALをTEMPORARYやTEMPの前に記述することができます。 PostgreSQLでは、現在違いがなく、廃止予定です。 互換性を参照してください。

If specified, the table is created as an unlogged table. Data written to unlogged tables is not written to the write-ahead log (see <xref linkend="wal"/>), which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. The contents of an unlogged table are also not replicated to standby servers. Any indexes created on an unlogged table are automatically unlogged as well. 指定された場合、テーブルはログを取らないテーブルとして作成されます。 ログを取らないテーブルに書き出されたデータは先行書き込みログ（第28章参照）には書き出されません。 このため通常のテーブルより相当高速になります。 しかしこれらはクラッシュ時に安全ではありません。 クラッシュまたは異常停止の後、ログを取らないテーブルは自動的に切り詰められます。 またログを取らないテーブルの内容はスタンバイサーバにコピーされません。 ログを取らないテーブル上に作成されたインデックスはすべて同様に、ログを取らないようになります。

If this is specified, any sequences created together with the unlogged table (for identity or serial columns) are also created as unlogged. これを指定すると、(ID列またはシリアル列用の)ログを取らないテーブルと一緒に作成されたシーケンスも、ログを取らないものとして作成されます。

Do not throw an error if a relation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing relation is anything like the one that would have been created. 同じ名前のリレーションがすでに存在していてもエラーとしません。 この場合注意が発せられます。 既存のリレーションが作成しようとしたものと何かしら似たものであることは保証されません。

The name (optionally schema-qualified) of the table to be created. 作成するテーブルの名前です（スキーマ修飾名でも可）。

Creates a <firstterm>typed table</firstterm>, which takes its structure from the specified composite type (name optionally schema-qualified). A typed table is tied to its type; for example the table will be dropped if the type is dropped (with <literal>DROP TYPE ... CASCADE</literal>). 指定した複合型(スキーマ修飾可能)から構造を取り出した型付きテーブルを作成します。 型付きテーブルはその型に束縛されます。 例えば、型が(DROP TYPE ... CASCADEで)削除されるとそのテーブルは削除されます。

When a typed table is created, then the data types of the columns are determined by the underlying composite type and are not specified by the <literal>CREATE TABLE</literal> command. But the <literal>CREATE TABLE</literal> command can add defaults and constraints to the table and can specify storage parameters. 型付きテーブルが作成されると、その列のデータ型は背後の複合型により決定され、CREATE TABLEコマンドでは指定されません。 しかしCREATE TABLEコマンドではテーブルにデフォルトと制約を追加できます。 また、格納パラメータの指定も可能です。

The name of a column to be created in the new table. 新しいテーブルで作成される列の名前です。

The data type of the column. This can include array specifiers. For more information on the data types supported by <productname>PostgreSQL</productname>, refer to <xref linkend="datatype"/>. 列のデータ型です。 これには、配列指定子を含めることができます。 PostgreSQLでサポートされるデータ型の情報に関する詳細は第8章を参照してください。

The <literal>COLLATE</literal> clause assigns a collation to the column (which must be of a collatable data type). If not specified, the column data type's default collation is used. COLLATE句は列（照合順の設定が可能なデータ型でなければなりません）に照合順を割り当てます。 指定がなければ、列のデータ型のデフォルトの照合順が使用されます。

This form sets the storage mode for the column. This controls whether this column is held inline or in a secondary <acronym>TOAST</acronym> table, and whether the data should be compressed or not. <literal>PLAIN</literal> must be used for fixed-length values such as <type>integer</type> and is inline, uncompressed. <literal>MAIN</literal> is for inline, compressible data. <literal>EXTERNAL</literal> is for external, uncompressed data, and <literal>EXTENDED</literal> is for external, compressed data. Writing <literal>DEFAULT</literal> sets the storage mode to the default mode for the column's data type. <literal>EXTENDED</literal> is the default for most data types that support non-<literal>PLAIN</literal> storage. Use of <literal>EXTERNAL</literal> will make substring operations on very large <type>text</type> and <type>bytea</type> values run faster, at the penalty of increased storage space. See <xref linkend="storage-toast"/> for more information. この構文は、列の格納モードを設定します。 これは、この列をインラインに保持するか、二次的なTOASTテーブルに保持するか、およびデータを圧縮する必要があるかどうかを制御します。 PLAINは、integerなどの固定長の値に使用することが必要で、インラインで、非圧縮です。 MAINはインラインで、圧縮可能なデータに対するものです。 EXTERNALは外部で、非圧縮データであり、EXTENDEDは外部で、圧縮されたデータに使用されます。 DEFAULTと書くと、列のデータ型に対して格納モードをデフォルトのモードに設定します。 EXTENDEDは、PLAIN以外の保管をサポートするほとんどのデータ型におけるデフォルトです。 EXTERNALを使用すると、非常に長いtextおよびbytea列に対する部分文字列操作の処理速度が向上しますが、必要な保管容量が増えるというデメリットがあります。 詳細は、65.2を参照してください。

The <literal>COMPRESSION</literal> clause sets the compression method for the column. Compression is supported only for variable-width data types, and is used only when the column's storage mode is <literal>main</literal> or <literal>extended</literal>. (See <xref linkend="sql-altertable"/> for information on column storage modes.) Setting this property for a partitioned table has no direct effect, because such tables have no storage of their own, but the configured value will be inherited by newly-created partitions. The supported compression methods are <literal>pglz</literal> and <literal>lz4</literal>. (<literal>lz4</literal> is available only if <option>&#45;-with-lz4</option> was used when building <productname>PostgreSQL</productname>.) In addition, <replaceable class="parameter">compression_method</replaceable> can be <literal>default</literal> to explicitly specify the default behavior, which is to consult the <xref linkend="guc-default-toast-compression"/> setting at the time of data insertion to determine the method to use. COMPRESSION句は列の圧縮方式を設定します。圧縮は可変幅データ型に対してのみサポートされていて、列の格納モードがmainまたはextendedの場合にのみ使われます。 (列の格納モードについての情報はALTER TABLEを参照してください。) パーティションテーブルには自身のストレージがありませんので、パーティションテーブルに対してこの属性を設定しても直接の影響はありませんが、設定値は新しく作成されるパーティションに継承されます。 サポートされている圧縮方式はpglzとlz4です。 (lz4は、PostgreSQL構築時に--with-lz4が使われた場合にのみ利用可能です。) さらにcompression_methodは、明示的にデフォルトの動作を指定するためにdefaultとすることもできます。その場合、利用する圧縮方式を決定するためにデータ挿入時にdefault_toast_compression設定を調べます。

The optional <literal>INHERITS</literal> clause specifies a list of tables from which the new table automatically inherits all columns. Parent tables can be plain tables or foreign tables. オプションのINHERITS句でテーブルの一覧を指定すると、新しいテーブルは指定されたテーブルの全ての列を自動的に継承します。 親テーブルには通常のテーブルまたは外部テーブルを指定できます。

Use of <literal>INHERITS</literal> creates a persistent relationship between the new child table and its parent table(s). Schema modifications to the parent(s) normally propagate to children as well, and by default the data of the child table is included in scans of the parent(s). INHERITSを使用すると、新しい子テーブルとその親テーブル（複数可）との間に永続的な関連が作成されます。 通常、親へのスキーマ変更は子にも伝播します。また、デフォルトでは、親テーブルのスキャン結果には子テーブルのデータが含まれます。

If the same column name exists in more than one parent table, an error is reported unless the data types of the columns match in each of the parent tables. If there is no conflict, then the duplicate columns are merged to form a single column in the new table. If the column name list of the new table contains a column name that is also inherited, the data type must likewise match the inherited column(s), and the column definitions are merged into one. If the new table explicitly specifies a default value for the column, this default overrides any defaults from inherited declarations of the column. Otherwise, any parents that specify default values for the column must all specify the same default, or an error will be reported. 複数の親テーブルに同一名の列が存在する場合、それらのデータ型が一致していなければ、エラーとして報告されます。 競合がなければ、これらの重複した列は新しいテーブルで1つの列の形に融合されます。 新しいテーブルの列名の一覧に継承する列の名前が含まれる場合も、そのデータ型は継承する列のデータ型と一致していなければなりません。さらに、その列定義は1つに融合されます。 新しいテーブルで明示的に列のデフォルト値を指定した場合、継承した列宣言における全てのデフォルト値は上書きされます。 デフォルト値を指定しなかった場合、親側でデフォルト値が指定されている時は、それらのデフォルト値が全て同じ値でなければなりません。 値が違う場合はエラーになります。

<literal>CHECK</literal> constraints are merged in essentially the same way as columns: if multiple parent tables and/or the new table definition contain identically-named <literal>CHECK</literal> constraints, these constraints must all have the same check expression, or an error will be reported. Constraints having the same name and expression will be merged into one copy. A constraint marked <literal>NO INHERIT</literal> in a parent will not be considered. Notice that an unnamed <literal>CHECK</literal> constraint in the new table will never be merged, since a unique name will always be chosen for it. CHECK制約は、基本的には列と同様の方法でマージされます。 複数の親テーブル、新しいテーブル、またはその両方の定義に同じ名前のCHECK制約が存在した場合、これらの制約はすべて同じ検査式を持たなければなりません。 さもなくば、エラーが報告されます。 同じ名前と式を持つ制約は１つのコピーにまとめられます。 親テーブルでNO INHERITと印が付いた制約は考慮されません。 新しいテーブル内の無名のCHECK制約は、一意な名前が必ず作られるため、マージされないことに注意してください。

Column <literal>STORAGE</literal> settings are also copied from parent tables. 列のSTORAGE設定もまた親テーブルからコピーされます。

If a column in the parent table is an identity column, that property is not inherited. A column in the child table can be declared identity column if desired. 親テーブルのある列がIDENTITY列の場合、その属性は継承されません。 望むなら子テーブルの列をIDENTITY列と宣言することができます。

The optional <literal>PARTITION BY</literal> clause specifies a strategy of partitioning the table. The table thus created is called a <firstterm>partitioned</firstterm> table. The parenthesized list of columns or expressions forms the <firstterm>partition key</firstterm> for the table. When using range or hash partitioning, the partition key can include multiple columns or expressions (up to 32, but this limit can be altered when building <productname>PostgreSQL</productname>), but for list partitioning, the partition key must consist of a single column or expression. オプションのPARTITION BY句により、テーブルのパーティショニングの戦略を指定できます。 このようにして作られたテーブルをパーティションテーブルと呼びます。 括弧に囲まれた列や式のリストはテーブルのパーティションキーを構成します。 範囲パーティションを使うときは、パーティションキーは複数の列または式にまたがることができます（最大で32ですが、この制限はPostgreSQLをビルドする時に変更できます）が、リストパーティションでは、パーティションキーは1つだけの列または式で構成されなければなりません。 パーティションテーブルの作成時にBツリー演算子クラスを指定しない場合は、そのデータ型のデフォルトのBツリー演算子クラスが使用されます。 Bツリー演算子クラスがない場合はエラーが報告されます。

Range and list partitioning require a btree operator class, while hash partitioning requires a hash operator class. If no operator class is specified explicitly, the default operator class of the appropriate type will be used; if no default operator class exists, an error will be raised. When hash partitioning is used, the operator class used must implement support function 2 (see <xref linkend="xindex-support"/> for details). 範囲とリストのパーティショニングはBツリー演算子クラスを必要とし、ハッシュパーティショニングはハッシュ演算子クラスを必要とします。 演算子クラスが明示的に指定されない場合、適当な型のデフォルトの演算子クラスが使われます。デフォルト演算子クラスがなければエラーが発生します。 ハッシュパーティショニングが使われているとき、使われる演算子クラスはサポート関数2を実装していなければなりません（詳しくは36.16.3を参照）。

A partitioned table is divided into sub-tables (called partitions), which are created using separate <literal>CREATE TABLE</literal> commands. The partitioned table is itself empty. A data row inserted into the table is routed to a partition based on the value of columns or expressions in the partition key. If no existing partition matches the values in the new row, an error will be reported. パーティションテーブルは（パーティションと呼ばれる）副テーブルに分割され、それらは別のCREATE TABLEコマンドにより作成されます。 パーティションテーブルそれ自体は空になります。 テーブルに挿入されるデータ行は、パーティションキーの列あるいは式の値に基づいて、1つのパーティションに回されます。 新しい行の値に適合するパーティションが存在しないときは、エラーが報告されます。

Partitioned tables do not support <literal>EXCLUDE</literal> constraints; however, you can define these constraints on individual partitions. パーティションテーブルはEXCLUDE制約をサポートしません。しかしながら、個々のパーティションにこの制約を定義することはできます。

See <xref linkend="ddl-partitioning"/> for more discussion on table partitioning. テーブルパーティショニングに関するより詳しい説明は5.12を参照してください。

Creates the table as a <firstterm>partition</firstterm> of the specified parent table. The table can be created either as a partition for specific values using <literal>FOR VALUES</literal> or as a default partition using <literal>DEFAULT</literal>. Any indexes, constraints and user-defined row-level triggers that exist in the parent table are cloned on the new partition. 指定した親テーブルのパーティションとしてテーブルを作成します。 FOR VALUESを用いて特定の値のパーティションとして、あるいは、DEFAULTを用いてデフォルトパーティションとしてテーブルを作成できます。 親テーブルにあるインデックス、制約、ユーザ定義の行レベルのトリガは新しいパーティションに複製されます。

The <replaceable class="parameter">partition_bound_spec</replaceable> must correspond to the partitioning method and partition key of the parent table, and must not overlap with any existing partition of that parent. The form with <literal>IN</literal> is used for list partitioning, the form with <literal>FROM</literal> and <literal>TO</literal> is used for range partitioning, and the form with <literal>WITH</literal> is used for hash partitioning. partition_bound_specは親テーブルのパーティショニング方法とパーティションキーに対応していなければならず、またそのテーブルのどの既存のパーティションとも重なり合ってはいけません。 INの構文はリストパーティショニングで、FROMとTOの構文は範囲パーティショニングで、WITHの構文はハッシュパーティショニングで、使用されます。

<replaceable class="parameter">partition_bound_expr</replaceable> is any variable-free expression (subqueries, window functions, aggregate functions, and set-returning functions are not allowed). Its data type must match the data type of the corresponding partition key column. The expression is evaluated once at table creation time, so it can even contain volatile expressions such as <literal><function>CURRENT_TIMESTAMP</function></literal>. partition_bound_exprは任意の無変数式です（サブクエリ、ウィンドウ関数、集約関数、複数行を返す関数は許されません）。 式のデータ型は対応するパーティションキー列と一致しなければなりません。 式はテーブル作成時に一度だけ評価されるため、CURRENT_TIMESTAMPなどの揮発性の式を含むことも可能です。

When creating a list partition, <literal>NULL</literal> can be specified to signify that the partition allows the partition key column to be null. However, there cannot be more than one such list partition for a given parent table. <literal>NULL</literal> cannot be specified for range partitions. リストパーティションを作るときは、NULLを指定することができて、それはそのパーティションではパーティションキーの列をNULLにすることができるということを意味します。 しかし、1つの親テーブルで2つ以上、そのようなリストパーティションを作ることはできません。 範囲パーティションではNULLを指定することはできません。

When creating a range partition, the lower bound specified with <literal>FROM</literal> is an inclusive bound, whereas the upper bound specified with <literal>TO</literal> is an exclusive bound. That is, the values specified in the <literal>FROM</literal> list are valid values of the corresponding partition key columns for this partition, whereas those in the <literal>TO</literal> list are not. Note that this statement must be understood according to the rules of row-wise comparison (<xref linkend="row-wise-comparison"/>). For example, given <literal>PARTITION BY RANGE (x,y)</literal>, a partition bound <literal>FROM (1, 2) TO (3, 4)</literal> allows <literal>x=1</literal> with any <literal>y&gt;=2</literal>, <literal>x=2</literal> with any non-null <literal>y</literal>, and <literal>x=3</literal> with any <literal>y&lt;4</literal>. 範囲パーティションを作るとき、FROMで指定する下限はそれを含む境界、TOで指定する上限はそれを含まない境界になります。 つまり、FROMリストで指定される値は、そのパーティションの対応するパーティションキー列において有効な値ですが、TOリストで指定される値はそうではない、ということです。 この文の意味は行単位の比較の規則（9.25.5）に従って理解しなければならないことに注意してください。 例えば、PARTITION BY RANGE (x,y)について、パーティション境界FROM (1, 2) TO (3, 4)には、x=1でy>=2の任意の値のもの、x=2でNULLでない任意のyのもの、x=3でy<4の任意の値のものが入ります。

The special values <literal>MINVALUE</literal> and <literal>MAXVALUE</literal> may be used when creating a range partition to indicate that there is no lower or upper bound on the column's value. For example, a partition defined using <literal>FROM (MINVALUE) TO (10)</literal> allows any values less than 10, and a partition defined using <literal>FROM (10) TO (MAXVALUE)</literal> allows any values greater than or equal to 10. 範囲パーティションを作るとき、MINVALUEおよびMAXVALUEという特別な値を使用することができて、これらはそれぞれ列の値に下限と上限がないことを示します。 例えば、FROM (MINVALUE) TO (10)で定義されたパーティションには10より小さいすべての値が入り、FROM (10) TO (MAXVALUE)で定義されたパーティションには10以上のすべての値が入ります。

When creating a range partition involving more than one column, it can also make sense to use <literal>MAXVALUE</literal> as part of the lower bound, and <literal>MINVALUE</literal> as part of the upper bound. For example, a partition defined using <literal>FROM (0, MAXVALUE) TO (10, MAXVALUE)</literal> allows any rows where the first partition key column is greater than 0 and less than or equal to 10. Similarly, a partition defined using <literal>FROM ('a', MINVALUE) TO ('b', MINVALUE)</literal> allows any rows where the first partition key column starts with "a". 2つ以上の列を含む範囲パーティションを作るとき、MAXVALUEを下限の一部として使うことや、MINVALUEを上限の一部として使うことも意味を持ちえます。 例えば、FROM (0, MAXVALUE) TO (10, MAXVALUE)で定義されたパーティションには、パーティションキーの第1列が0より大きく、かつ10以下であるものが入ります。 同様に、FROM ('a', MINVALUE) TO ('b', MINVALUE)で定義されたパーティションには、パーティションキーの第1列が"a"で始まるすべての行が入ります。

Note that if <literal>MINVALUE</literal> or <literal>MAXVALUE</literal> is used for one column of a partitioning bound, the same value must be used for all subsequent columns. For example, <literal>(10, MINVALUE, 0)</literal> is not a valid bound; you should write <literal>(10, MINVALUE, MINVALUE)</literal>. MINVALUEまたはMAXVALUEをパーティション境界の1つの列で使用する場合、それより後の列では同じ値を使用しなければならないことに注意してください。 例えば、(10, MINVALUE, 0)は有効な境界ではありません。 (10, MINVALUE, MINVALUE)とします。

Also note that some element types, such as <literal>timestamp</literal>, have a notion of "infinity", which is just another value that can be stored. This is different from <literal>MINVALUE</literal> and <literal>MAXVALUE</literal>, which are not real values that can be stored, but rather they are ways of saying that the value is unbounded. <literal>MAXVALUE</literal> can be thought of as being greater than any other value, including "infinity" and <literal>MINVALUE</literal> as being less than any other value, including "minus infinity". Thus the range <literal>FROM ('infinity') TO (MAXVALUE)</literal> is not an empty range; it allows precisely one value to be stored &mdash; "infinity". timestampなど一部の要素型では、"infinity"（無限）の概念があり、それも保存できる値であることにも注意してください。 MINVALUEとMAXVALUEは保存できる真の値ではなく、値に境界がないということを表現するための方法に過ぎないため、これとは違います。 MAXVALUEは"infinity"も含め、他のすべての値より大きいものと考えることができ、またMINVALUEは"minus infinity"も含め、他のすべての値より小さいものと考えることができます。 従って、境界FROM ('infinity') TO (MAXVALUE)は空の範囲ではなく、たった1つの値、つまり"infinity"だけを保存します。

If <literal>DEFAULT</literal> is specified, the table will be created as the default partition of the parent table. This option is not available for hash-partitioned tables. A partition key value not fitting into any other partition of the given parent will be routed to the default partition. DEFAULTが指定された場合、テーブルは親テーブルのデフォルトパーティションとして作成されます。 本オプションはハッシュパーティションされたテーブルには使用できません。 親の他のどのパーティションにも当てはまらないパーティションキー値はデフォルトパーティションに送られます。

When a table has an existing <literal>DEFAULT</literal> partition and a new partition is added to it, the default partition must be scanned to verify that it does not contain any rows which properly belong in the new partition. If the default partition contains a large number of rows, this may be slow. The scan will be skipped if the default partition is a foreign table or if it has a constraint which proves that it cannot contain rows which should be placed in the new partition. テーブルが既存のDEFAULTパーティションを持っていて、新たなパーティションが追加された場合、デフォルトパーティションは、新たなパーティションに属すのがふさわしい行が含まれていないことを確かめるために、検査されなければなりません。 デフォルトパーティションに多数の行が含まれている場合、これは時間を要すかもしれません。 デフォルトパーティションが、外部テーブルであるか、新パーティションに置くべき行を含むことができないことを証明する制約を持つ場合、この検査は省略されます。

When creating a hash partition, a modulus and remainder must be specified. The modulus must be a positive integer, and the remainder must be a non-negative integer less than the modulus. Typically, when initially setting up a hash-partitioned table, you should choose a modulus equal to the number of partitions and assign every table the same modulus and a different remainder (see examples, below). However, it is not required that every partition have the same modulus, only that every modulus which occurs among the partitions of a hash-partitioned table is a factor of the next larger modulus. This allows the number of partitions to be increased incrementally without needing to move all the data at once. For example, suppose you have a hash-partitioned table with 8 partitions, each of which has modulus 8, but find it necessary to increase the number of partitions to 16. You can detach one of the modulus-8 partitions, create two new modulus-16 partitions covering the same portion of the key space (one with a remainder equal to the remainder of the detached partition, and the other with a remainder equal to that value plus 8), and repopulate them with data. You can then repeat this &#45;- perhaps at a later time &#45;- for each modulus-8 partition until none remain. While this may still involve a large amount of data movement at each step, it is still better than having to create a whole new table and move all the data at once. ハッシュパーティションを作るときには法と残余を指定しなければなりません。 法は正の整数でなければならず、残余は法よりも小さい非負整数でなければなりません。 典型的にはハッシュパーティションテーブル初期設定をするとき、パーティションの数と等しい法を選び、全てのテーブルに同じ法と異なる残余を割り当てます（後述の例を参照）。 しかしながら、全てのパーティションが同じ法を持つ必要はなく、あるハッシュパーティションテーブルのパーティションに存在する全ての法が次に大きい法の因子であることだけ必要です。 このことは、全データを一度に移すことなくパーティション数を徐々に増やすことを可能にします。 例えば、各々の法が8である8パーティションのハッシュパーティションテーブルがあるとして、パーティション数を16に増やさなければならなくなったとします。 私たちは8を法とするパーティションの一つをデタッチして、新たに16を法とするキー空間の同じ部分（一つはデタッチしたパーティションと等しい残余を持ち、一つはその値に8を加えたのと等しい残余を持つ）を対象とする二つのパーティションを追加して、データを再配置することができます。 これを（おそらくはより後に）8を法とする各パーティションがなくなるまで、繰り返すことができます。 これは依然として各ステップで大きなデータ移動を伴いますが、全体の新テーブルを作って全データを一度に移さなければならないというよりは、まだ良いです。

A partition must have the same column names and types as the partitioned table to which it belongs. Modifications to the column names or types of a partitioned table will automatically propagate to all partitions. <literal>CHECK</literal> constraints will be inherited automatically by every partition, but an individual partition may specify additional <literal>CHECK</literal> constraints; additional constraints with the same name and condition as in the parent will be merged with the parent constraint. Defaults may be specified separately for each partition. But note that a partition's default value is not applied when inserting a tuple through a partitioned table. パーティションは、それが属するパーティションテーブルと同じ列名および型を持っていなければなりません。 パーティションテーブルの列名や型の変更は自動的にすべてのパーティションに反映されます。 CHECK制約はすべてのパーティションで自動的に継承されますが、個々のパーティションで追加のCHECK制約を指定することができます。 親の制約と同じ名前と条件を持つ追加制約は親の制約と統合されます。 デフォルト制約は各パーティションで別々に指定できます。 ですが、パーティションのデフォルト値は、パーティションテーブルを通してタプルを挿入する場合には適用されないことに注意してください。

Rows inserted into a partitioned table will be automatically routed to the correct partition. If no suitable partition exists, an error will occur. パーティションテーブルに挿入された行は、自動的に正しいパーティションに回されます。 適当なパーティションが存在しないときは、エラーが発生します。

Operations such as <command>TRUNCATE</command> which normally affect a table and all of its inheritance children will cascade to all partitions, but may also be performed on an individual partition. TRUNCATEのように通常はテーブルとそれを継承するすべての子テーブルに影響を及ぼす操作は、すべてのパーティションに対しても適用されますが、個別のパーティションに対して操作することも可能です。

Note that creating a partition using <literal>PARTITION OF</literal> requires taking an <literal>ACCESS EXCLUSIVE</literal> lock on the parent partitioned table. Likewise, dropping a partition with <command>DROP TABLE</command> requires taking an <literal>ACCESS EXCLUSIVE</literal> lock on the parent table. It is possible to use <link linkend="sql-altertable"><command>ALTER TABLE ATTACH/DETACH PARTITION</command></link> to perform these operations with a weaker lock, thus reducing interference with concurrent operations on the partitioned table. PARTITION OFを使用してパーティションを作成するには、親のパーティション化されたテーブルでACCESS EXCLUSIVEロックを取得する必要があることに注意してください。 同様に、DROP TABLEでパーティションを削除するには、親テーブルについてACCESS EXCLUSIVEロックを取得する必要があります。 パーティション化されたテーブルでの同時操作による干渉を減らし、より弱いロックでこれらの操作を実行するため、ALTER TABLE ATTACH/DETACH PARTITIONを使用できます。

The <literal>LIKE</literal> clause specifies a table from which the new table automatically copies all column names, their data types, and their not-null constraints. LIKE句にテーブルを指定すると、自動的にそのテーブルの全ての列名、そのデータ型、非NULL制約が新しいテーブルにコピーされます。

Unlike <literal>INHERITS</literal>, the new table and original table are completely decoupled after creation is complete. Changes to the original table will not be applied to the new table, and it is not possible to include data of the new table in scans of the original table. INHERITSとは違い、作成した後、新しいテーブルと元のテーブルが完全に分離されます。 元のテーブルへの変更は新しいテーブルには適用されません。また、元のテーブルをスキャンしても新しいテーブルのデータは見つかりません。

Also unlike <literal>INHERITS</literal>, columns and constraints copied by <literal>LIKE</literal> are not merged with similarly named columns and constraints. If the same name is specified explicitly or in another <literal>LIKE</literal> clause, an error is signaled. INHERITSと異なり、LIKEによりコピーされた列や制約は類似の名前の列や制約にまとめられません。 同じ名前が明示的に、あるいは他のLIKE句で指定された場合、エラーが通知されます。

The optional <replaceable>like_option</replaceable> clauses specify which additional properties of the original table to copy. Specifying <literal>INCLUDING</literal> copies the property, specifying <literal>EXCLUDING</literal> omits the property. <literal>EXCLUDING</literal> is the default. If multiple specifications are made for the same kind of object, the last one is used. The available options are: オプションのlike_option句は元テーブルのどの追加属性をコピーするかを指定します。 INCLUDING指定は属性をコピーし、EXCLUDING指定は属性を省きます。 EXCLUDINGがデフォルトです。 同種の対象に複数の指定がある場合には最後のものが使われます。 指定可能なオプションは以下です。

The <literal>LIKE</literal> clause can also be used to copy column definitions from views, foreign tables, or composite types. Inapplicable options (e.g., <literal>INCLUDING INDEXES</literal> from a view) are ignored. またLIKE句をビュー、外部テーブル、複合型から列の定義をコピーするために使用することができます。 適用できないオプション（ビューからのINCLUDING INDEXESなど）は無視されます。

An optional name for a column or table constraint. If the constraint is violated, the constraint name is present in error messages, so constraint names like <literal>col must be positive</literal> can be used to communicate helpful constraint information to client applications. (Double-quotes are needed to specify constraint names that contain spaces.) If a constraint name is not specified, the system generates a name. 列制約、テーブル制約の名前(省略可能)です。 制約に違反すると、制約名がエラーメッセージに含まれます。 ですので、col must be positive(正数でなければならない)といった名前の制約名を付与することで、クライアントアプリケーションへ有用な制約情報を渡すことができます。 （空白を含む制約名を指定する場合、二重引用符が必要です。） 指定されなければ、システムが名前を生成します。

The column is not allowed to contain null values. その列がNULL値を持てないことを指定します。

The column is allowed to contain null values. This is the default. その列がNULL値を持てることを指定します。 これがデフォルトです。

This clause is only provided for compatibility with non-standard SQL databases. Its use is discouraged in new applications. この句は非標準的なSQLデータベースとの互換性のためだけに提供されています。 新しいアプリケーションでこれを使用するのはお勧めしません。

The <literal>CHECK</literal> clause specifies an expression producing a Boolean result which new or updated rows must satisfy for an insert or update operation to succeed. Expressions evaluating to TRUE or UNKNOWN succeed. Should any row of an insert or update operation produce a FALSE result, an error exception is raised and the insert or update does not alter the database. A check constraint specified as a column constraint should reference that column's value only, while an expression appearing in a table constraint can reference multiple columns. CHECK句は、論理型の結果を生成する、新しい行または更新される行が挿入または更新処理を成功させるために満足しなければならない式を指定します。 TRUEまたはUNKNOWNと評価される式は成功します。 挿入または更新処理の行がFALSEという結果をもたらす場合はエラー例外が発生し、その挿入または更新によるデータベースの変更は行われません。 列制約として指定された検査制約は列の値のみを参照しなければなりません。 テーブル制約内の式は複数の列を参照できます。

Currently, <literal>CHECK</literal> expressions cannot contain subqueries nor refer to variables other than columns of the current row (see <xref linkend="ddl-constraints-check-constraints"/>). The system column <literal>tableoid</literal> may be referenced, but not any other system column. 現時点では、CHECK式には副問い合わせも現在の行の列以外の変数も含めることはできません（5.5.1を参照）。 システム列tableoidを参照することはできますが、他のシステム列は参照できません。

A constraint marked with <literal>NO INHERIT</literal> will not propagate to child tables. NO INHERITと印が付いた制約は子テーブルには伝搬しません。

When a table has multiple <literal>CHECK</literal> constraints, they will be tested for each row in alphabetical order by name, after checking <literal>NOT NULL</literal> constraints. (<productname>PostgreSQL</productname> versions before 9.5 did not honor any particular firing order for <literal>CHECK</literal> constraints.) テーブルに複数のCHECK制約がある場合、それらはNOT NULL制約について検証した後で、各行について名前のアルファベット順に検証されます。 （PostgreSQLの9.5より前のバージョンでは、CHECK制約の実行について特定の順序はありませんでした。）

The <literal>DEFAULT</literal> clause assigns a default data value for the column whose column definition it appears within. The value is any variable-free expression (in particular, cross-references to other columns in the current table are not allowed). Subqueries are not allowed either. The data type of the default expression must match the data type of the column. DEFAULT句を列定義に付けると、その列にデフォルトデータ値が割り当てられます。 値として指定するのは任意の無変数式です（特に現在のテーブル内の他の列へクロス参照はできません）。 副問い合わせも指定できません。 デフォルト式のデータ型はその列のデータ型と一致する必要があります。

The default expression will be used in any insert operation that does not specify a value for the column. If there is no default for a column, then the default is null. デフォルト式は、全ての挿入操作において、その列に値が指定されていない場合に使用されます。 列にデフォルト値がない場合、デフォルト値はNULLになります。

This clause creates the column as a <firstterm>generated column</firstterm>. The column cannot be written to, and when read the result of the specified expression will be returned. この句は列を生成列として作成します。 この列には書き込みできず、読むときには指定された式の結果が返されます。

The keyword <literal>STORED</literal> is required to signify that the column will be computed on write and will be stored on disk. キーワードSTOREDは列が書き込み時に計算されてディスクに格納されることをあらわすのに必要とされます。

The generation expression can refer to other columns in the table, but not other generated columns. Any functions and operators used must be immutable. References to other tables are not allowed. 生成式はそのテーブルの他の列を参照できますが、他の生成列は参照できません。 使われる全ての関数と演算子はIMMUTABLEでなければなりません。 他テーブルを参照することはできません。

This clause creates the column as an <firstterm>identity column</firstterm>. It will have an implicit sequence attached to it and in newly-inserted rows the column will automatically have values from the sequence assigned to it. Such a column is implicitly <literal>NOT NULL</literal>. 《マッチ度[80.000000]》この句は列をIDENTITY列として作成します。 それには暗黙のシーケンスが紐付けられ、新しい行のその列には紐付けられたシーケンスから取られた値が自動的に入ります。 そのような列は暗黙的にNOT NULLです。 《機械翻訳》この句は、カラムを識別カラムとして作成します。 暗黙的なシーケンスが付加され、新しく挿入された行では、カラムは自動的にシーケンスアサインからの値を持ちます。 このようなカラムは暗黙的NOT NULLになります。

The clauses <literal>ALWAYS</literal> and <literal>BY DEFAULT</literal> determine how explicitly user-specified values are handled in <command>INSERT</command> and <command>UPDATE</command> commands. ALWAYSとBY DEFAULTの句は、INSERTやUPDATEコマンドで明示的にユーザが指定した値をどのように扱うかを決定します。

In an <command>INSERT</command> command, if <literal>ALWAYS</literal> is selected, a user-specified value is only accepted if the <command>INSERT</command> statement specifies <literal>OVERRIDING SYSTEM VALUE</literal>. If <literal>BY DEFAULT</literal> is selected, then the user-specified value takes precedence. See <xref linkend="sql-insert"/> for details. (In the <command>COPY</command> command, user-specified values are always used regardless of this setting.) INSERTコマンドでは、ALWAYSが選択された場合、ユーザの指定した値はINSERT文がOVERRIDING SYSTEM VALUEを指定している場合にのみ受け付けられます。 BY DEFAULTが選択された場合、ユーザの指定した値が優先します。 詳細はINSERTを参照してください。 (COPYコマンドでは、この設定に関係なく、ユーザの指定した値が常に使われます。)

In an <command>UPDATE</command> command, if <literal>ALWAYS</literal> is selected, any update of the column to any value other than <literal>DEFAULT</literal> will be rejected. If <literal>BY DEFAULT</literal> is selected, the column can be updated normally. (There is no <literal>OVERRIDING</literal> clause for the <command>UPDATE</command> command.) UPDATEでは、ALWAYSが選択された場合、DEFAULT以外の値への列の更新は拒絶されます。 BY DEFAULTが選択された場合、列は普通に更新されます。 (UPDATEコマンドにOVERRIDING句はありません。)

The optional <replaceable>sequence_options</replaceable> clause can be used to override the parameters of the sequence. The available options include those shown for <xref linkend="sql-createsequence"/>, plus <literal>SEQUENCE NAME <replaceable>name</replaceable></literal>, <literal>LOGGED</literal>, and <literal>UNLOGGED</literal>, which allow selection of the name and persistence level of the sequence. Without <literal>SEQUENCE NAME</literal>, the system chooses an unused name for the sequence. Without <literal>LOGGED</literal> or <literal>UNLOGGED</literal>, the sequence will have the same persistence level as the table. 《機械翻訳》オプショナルシーケンス_オプション句は、シーケンスのパラメータを上書きするために使用できます。 使用可能なオプションincludeはCREATE SEQUENCE、プラスシーケンス名前名前、LOGGED、UNLOGGEDに対して表示され、名前の選択とシーケンスの永続レベルを許可します。 シーケンス名前がない場合、システムはシーケンスに未使用の名前を選択します。 LOGGEDまたはUNLOGGEDを指定しない場合、シーケンスはテーブルと同じ永続レベルを持ちます。

The <literal>UNIQUE</literal> constraint specifies that a group of one or more columns of a table can contain only unique values. The behavior of a unique table constraint is the same as that of a unique column constraint, with the additional capability to span multiple columns. The constraint therefore enforces that any two rows must differ in at least one of these columns. UNIQUE制約は、テーブルの1つまたは複数の列からなるグループが、一意な値のみを持つことができることを指定します。 一意性テーブル制約の動作は一意性列制約と同じですが、さらに複数列にまたがる機能を持ちます。 それゆえ、制約は2つの行はその列の少なくとも1つが異なることを強制します。

For the purpose of a unique constraint, null values are not considered equal, unless <literal>NULLS NOT DISTINCT</literal> is specified. 一意性制約では、NULLS NOT DISTINCTが指定されない限り、NULL値同士は等しいとはみなされなせん。

Each unique constraint should name a set of columns that is different from the set of columns named by any other unique or primary key constraint defined for the table. (Otherwise, redundant unique constraints will be discarded.) それぞれの一意性制約には、そのテーブルの他の一意性制約もしくは主キー制約によって指定された列の集合とは、異なる列の集合を指定しなければなりません。 （そうでなければ、余分な一意性制約は捨てられます。）

When establishing a unique constraint for a multi-level partition hierarchy, all the columns in the partition key of the target partitioned table, as well as those of all its descendant partitioned tables, must be included in the constraint definition. 複数レベルのパーティション階層に一意性制約を設定するとき、対象パーティションテーブル、および全ての子孫のパーティションテーブルの、パーティションキー内の全ての列が制約定義に含まれなくてはなりません。

Adding a unique constraint will automatically create a unique btree index on the column or group of columns used in the constraint. The created index has the same name as the unique constraint. 《マッチ度[61.658031]》一意性制約を加えると、制約で使われている列や列のグループに一意性btreeインデックスが自動的に作られます。 《機械翻訳》一意性制約を追加すると、制約で使用される列や列のグループに、ユニークBtreeインデックスが自動的に作成されます。 作成されたインデックスには、一意性制約と同じ名前があります。

The optional <literal>INCLUDE</literal> clause adds to that index one or more columns that are simply <quote>payload</quote>: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., <literal>DROP COLUMN</literal>) can cause cascaded constraint and index deletion. 省略可能なINCLUDE句はインデックスに単に「ペイロード」である列を1つまたは複数、追加します。一意性はその列には強要されず、その列に基づいてインデックスが検索されることはありません。 しかしながら、インデックスオンリースキャンでは取り出すことができます。 含めた（INCLUDEした）列に制約は強制されませんが、依存はしていることに注意してください。 このため、これらの列に対する一部の操作（例えばDROP COLUMN）は制約の連鎖とインデックスの削除をひき起こすことがあります。

The <literal>PRIMARY KEY</literal> constraint specifies that a column or columns of a table can contain only unique (non-duplicate), nonnull values. Only one primary key can be specified for a table, whether as a column constraint or a table constraint. PRIMARY KEY制約はテーブルの一列または複数の列が一意（重複がない）で、非NULLの値のみを持つことを指定します。 列制約かテーブル制約かに関わらず、１つのテーブルには主キーを１つだけ指定できます。

The primary key constraint should name a set of columns that is different from the set of columns named by any unique constraint defined for the same table. (Otherwise, the unique constraint is redundant and will be discarded.) 主キー制約では、同じテーブルに一意制約で指定した列の集合とは異なる列の集合を指定します。 （そうでなければ、一意制約は冗長となり、捨てられます。）

<literal>PRIMARY KEY</literal> enforces the same data constraints as a combination of <literal>UNIQUE</literal> and <literal>NOT NULL</literal>. However, identifying a set of columns as the primary key also provides metadata about the design of the schema, since a primary key implies that other tables can rely on this set of columns as a unique identifier for rows. PRIMARY KEYはUNIQUEとNOT NULLの組み合わせと同じデータ制約を課します。 ですが、列の集合を主キーと指定することは、スキーマの設計についてのメタデータを提供することにもなります。 なぜなら、主キーであることは、行を一意に特定するものとして、他のテーブルがその列の集合を当てにして良い、ということを意味するからです。

When placed on a partitioned table, <literal>PRIMARY KEY</literal> constraints share the restrictions previously described for <literal>UNIQUE</literal> constraints. パーティションテーブルに設定すると、PRIMARY KEY制約は、以前述べた制限をUNIQUE制約と共有します。

Adding a <literal>PRIMARY KEY</literal> constraint will automatically create a unique btree index on the column or group of columns used in the constraint. That index has the same name as the primary key constraint. 《マッチ度[68.837209]》PRIMARY KEY制約を追加すると、制約で使用する列や列のグループに一意性のbtreeインデックスが自動的に作られます。 《機械翻訳》主キー制約を追加すると、制約で使用されている列や列のグループにユニークBtreeインデックスが自動的に作成されます。 そのインデックスには主キー制約と同じ名前があります。

The optional <literal>INCLUDE</literal> clause adds to that index one or more columns that are simply <quote>payload</quote>: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., <literal>DROP COLUMN</literal>) can cause cascaded constraint and index deletion. 省略可能なINCLUDE句はインデックスに単に「ペイロード」である列を1つまたは複数、追加します。一意性はその列には強要されず、その列に基づいてインデックスが検索されることはありません。 しかしながら、インデックスオンリースキャンでは取り出すことができます。 含めた列に一意性は強制されませんが、制約はこれらに依存はしています。 このため、これらの列に対する一部の操作（例えばDROP COLUMN）は制約の連鎖とインデックスの削除をひき起こすことがあります。

The <literal>EXCLUDE</literal> clause defines an exclusion constraint, which guarantees that if any two rows are compared on the specified column(s) or expression(s) using the specified operator(s), not all of these comparisons will return <literal>TRUE</literal>. If all of the specified operators test for equality, this is equivalent to a <literal>UNIQUE</literal> constraint, although an ordinary unique constraint will be faster. However, exclusion constraints can specify constraints that are more general than simple equality. For example, you can specify a constraint that no two rows in the table contain overlapping circles (see <xref linkend="datatype-geometric"/>) by using the <literal>&amp;&amp;</literal> operator. The operator(s) are required to be commutative. EXCLUDE句は排他制約を定義し、任意の2行について指定した列(複数可)または式(複数可)を指定した演算子(複数可)を使用して比較した場合、比較結果のすべてがTRUEを返さないことを保証します。 指定した演算子のすべてが等価性を試験するものであれば、これはUNIQUE制約と同じですが、通常の一意性制約のほうが高速です。 しかし、排他制約では単純な等価性よりも一般的な制約を指定することができます。 例えば、テーブル内の2つの行が重複する円(8.8参照)を持たないといった制約を&&演算子を使用して指定することができます。 演算子は可換であることが必要です。

Exclusion constraints are implemented using an index that has the same name as the constraint, so each specified operator must be associated with an appropriate operator class (see <xref linkend="indexes-opclass"/>) for the index access method <replaceable>index_method</replaceable>. Each <replaceable class="parameter">exclude_element</replaceable> defines a column of the index, so it can optionally specify a collation, an operator class, operator class parameters, and/or ordering options; these are described fully under <xref linkend="sql-createindex"/>. 《マッチ度[84.135472]》排他制約はインデックスを使用して実装されています。 このため指定した演算子はそれぞれ適切な演算子クラス(11.10参照)でindex_methodインデックスアクセスメソッドと関連付けされていなければなりません。 各exclude_elementはインデックスの列を定義しますので、オプションで、照合順序、演算子クラス、演算子クラスパラメータ、および/または順序付けオプションを指定できます。これらについてはCREATE INDEXで説明します。 《機械翻訳》排他制約は、制約と同じ名前のインデックスを使用して実装されます。 したがって、指定された各演算子は、インデックスアクセスメソッドindex_methodに対して適切な演算子クラス（11.10を参照）に関連付けられていなければなりません。 各exclude_elementはインデックスの列を定義します。 したがって、オプションで、照合順序、演算子クラス、演算子クラスパラメータ、および/または順序付けオプションを指定できます。 これらについてはCREATE INDEXで詳しく説明します。

The access method must support <literal>amgettuple</literal> (see <xref linkend="indexam"/>); at present this means <acronym>GIN</acronym> cannot be used. Although it's allowed, there is little point in using B-tree or hash indexes with an exclusion constraint, because this does nothing that an ordinary unique constraint doesn't do better. So in practice the access method will always be <acronym>GiST</acronym> or <acronym>SP-GiST</acronym>. アクセスメソッドはamgettupleをサポートしなければなりません(第62章参照)。 現時点では、これはGINを使用できないことを意味します。 B-treeやHashインデックスを排他制約で使用することは許容されますが、そうすることにあまり意味はありません。 これが通常の一意性制約より良いことは何もないからです。 このため現実的にはアクセスメソッドは常にGiSTもしくはSP-GiSTとなります。

The <replaceable class="parameter">predicate</replaceable> allows you to specify an exclusion constraint on a subset of the table; internally this creates a partial index. Note that parentheses are required around the predicate. predicateにより、排他制約をテーブルの部分集合に指定することができます。 内部的には、これは部分インデックスを作成します。 predicateの前後に括弧が必要であることに注意して下さい。

These clauses specify a foreign key constraint, which requires that a group of one or more columns of the new table must only contain values that match values in the referenced column(s) of some row of the referenced table. If the <replaceable class="parameter">refcolumn</replaceable> list is omitted, the primary key of the <replaceable class="parameter">reftable</replaceable> is used. Otherwise, the <replaceable class="parameter">refcolumn</replaceable> list must refer to the columns of a non-deferrable unique or primary key constraint or be the columns of a non-partial unique index. The user must have <literal>REFERENCES</literal> permission on the referenced table (either the whole table, or the specific referenced columns). The addition of a foreign key constraint requires a <literal>SHARE ROW EXCLUSIVE</literal> lock on the referenced table. Note that foreign key constraints cannot be defined between temporary tables and permanent tables. これらの句は、外部キー制約を指定します。 外部キー制約は、新しいテーブルの1つまたは複数の列の集合が、被参照テーブルの一部の行の被参照列に一致する値を持たなければならないことを指定するものです。 refcolumnリストが省略された場合、reftableの主キーが使用されます。 そうでない場合、refcolumnリストは遅延不可の一意性または主キー制約の列を参照するか、部分インデックスでない一意インデックスの列でなければなりません。 被参照列は、被参照テーブルにおいて遅延不可の一意性制約もしくは主キー制約を持った列でなければなりません。 ユーザは被参照テーブル（テーブル全体または特定の被参照列）についてREFERENCES権限を持っていなければなりません。 外部キー制約の追加は被参照テーブルにSHARE ROW EXCLUSIVEロックを必要とします。 一時テーブルと永続テーブルとの間で外部キー制約を定義できないことに注意してください。

A value inserted into the referencing column(s) is matched against the values of the referenced table and referenced columns using the given match type. There are three match types: <literal>MATCH FULL</literal>, <literal>MATCH PARTIAL</literal>, and <literal>MATCH SIMPLE</literal> (which is the default). <literal>MATCH FULL</literal> will not allow one column of a multicolumn foreign key to be null unless all foreign key columns are null; if they are all null, the row is not required to have a match in the referenced table. <literal>MATCH SIMPLE</literal> allows any of the foreign key columns to be null; if any of them are null, the row is not required to have a match in the referenced table. <literal>MATCH PARTIAL</literal> is not yet implemented. (Of course, <literal>NOT NULL</literal> constraints can be applied to the referencing column(s) to prevent these cases from arising.) 参照列に挿入された値は、被参照テーブルと被参照列の値に対して、指定した照合型で照会されます。 照合型には3種類があります。 MATCH FULL、MATCH PARTIAL、MATCH SIMPLE（これがデフォルト）照合型です。 MATCH FULLは全ての外部キー列がNULLとなる場合を除き、複数列外部キーのある列がNULLとなることを許可しません。 それらがすべてNULLであれば、その行は被参照テーブル内で一致があることは要求されません。 MATCH SIMPLEは、外部キーの一部がNULLであることを許可します。 それらの一部がNULLであれば、その行は被参照テーブル内で一致があることは要求されません。 MATCH PARTIALはまだ実装されていません。 （当然ですが、NOT NULL制約を参照列に適用し、こうした状態が発生することを防止することができます。）

In addition, when the data in the referenced columns is changed, certain actions are performed on the data in this table's columns. The <literal>ON DELETE</literal> clause specifies the action to perform when a referenced row in the referenced table is being deleted. Likewise, the <literal>ON UPDATE</literal> clause specifies the action to perform when a referenced column in the referenced table is being updated to a new value. If the row is updated, but the referenced column is not actually changed, no action is done. Referential actions other than the <literal>NO ACTION</literal> check cannot be deferred, even if the constraint is declared deferrable. There are the following possible actions for each clause: さらに、被参照列のデータが変更された場合、このテーブルの列のデータに何らかの動作が発生します。 ON DELETE句は、被参照テーブルの被参照行が削除されようとした場合の動作を指定します。 同様にON UPDATE句は、被参照テーブルの被参照列が新しい値に更新されようとした場合の動作を指定します。 行の更新があった場合でも、被参照列が実際に変更されない場合は、動作は実行されません。 制約が遅延可能と宣言されていても、NO ACTION検査以外の参照動作は遅延させられません。 各句について、以下の動作を指定可能です。

If the referenced column(s) are changed frequently, it might be wise to add an index to the referencing column(s) so that referential actions associated with the foreign key constraint can be performed more efficiently. 被参照列が頻繁に更新される場合、参照列にインデックスを付け、その外部キー制約に関連する参照動作がより効率的に実行できるようにする方が良いでしょう。

This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command. Checking of constraints that are deferrable can be postponed until the end of the transaction (using the <link linkend="sql-set-constraints"><command>SET CONSTRAINTS</command></link> command). <literal>NOT DEFERRABLE</literal> is the default. Currently, only <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>, <literal>EXCLUDE</literal>, and <literal>REFERENCES</literal> (foreign key) constraints accept this clause. <literal>NOT NULL</literal> and <literal>CHECK</literal> constraints are not deferrable. Note that deferrable constraints cannot be used as conflict arbitrators in an <command>INSERT</command> statement that includes an <literal>ON CONFLICT DO UPDATE</literal> clause. 制約を遅延させることが可能かどうかを制御します。 遅延不可の制約は各コマンドの後すぐに検査されます。 遅延可能な制約の検査は、（SET CONSTRAINTSコマンドを使用して）トランザクションの終了時まで遅延させることができます。 NOT DEFERRABLEがデフォルトです。 現在、UNIQUE、PRIMARY KEY、EXCLUDE、REFERENCES（外部キー）制約のみがこの句を受け付けることができます。 NOT NULLおよび CHECK制約は遅延させることができません。 遅延可能な制約はON CONFLICT DO UPDATE句を含むINSERT文において、競合解決のために使うことはできないことに注意してください。

If a constraint is deferrable, this clause specifies the default time to check the constraint. If the constraint is <literal>INITIALLY IMMEDIATE</literal>, it is checked after each statement. This is the default. If the constraint is <literal>INITIALLY DEFERRED</literal>, it is checked only at the end of the transaction. The constraint check time can be altered with the <link linkend="sql-set-constraints"><command>SET CONSTRAINTS</command></link> command. 制約が遅延可能な場合、この句は制約検査を行うデフォルトの時期を指定します。 制約がINITIALLY IMMEDIATEの場合、各文の実行後に検査されます。 これがデフォルトです。 制約がINITIALLY DEFERREDの場合、トランザクションの終了時にのみ検査されます。 制約検査の時期はSET CONSTRAINTSコマンドを使用して変更することができます。

This optional clause specifies the table access method to use to store the contents for the new table; the method needs be an access method of type <literal>TABLE</literal>. See <xref linkend="tableam"/> for more information. If this option is not specified, the default table access method is chosen for the new table. See <xref linkend="guc-default-table-access-method"/> for more information. このオプションの句は新しいテーブルの中身の格納に用いるテーブルアクセスメソッドを指定します。指定するものは、TABLEタイプのアクセスメソッドでなければなりません。 より詳しい情報は第61章を参照してください。 このオプションが指定されない場合、新しいテーブルにはデフォルトテーブルアクセスメソッドが選択されます。 より詳しい情報はdefault_table_access_methodを参照してください。

When creating a partition, the table access method is the access method of its partitioned table, if set. 《機械翻訳》パーティションを作成するとき、テーブルアクセスメソッドは、設定されている場合、そのパーティションテーブルのアクセスメソッドになります。

This clause specifies optional storage parameters for a table or index; see <xref linkend="sql-createtable-storage-parameters"/> below for more information. For backward-compatibility the <literal>WITH</literal> clause for a table can also include <literal>OIDS=FALSE</literal> to specify that rows of the new table should not contain OIDs (object identifiers), <literal>OIDS=TRUE</literal> is not supported anymore. この句はテーブルまたはインデックスに対するオプションの格納パラメータを指定します。 詳しくは格納パラメータを参照してください。 後方互換性のため、テーブルに対するWITH句には新しいテーブルの行にOID（オブジェクト識別子）が含まれないことを示すためにOIDS=FALSEを含めることもできます。OIDS=TRUEはもはやサポートされません。

This is backward-compatible syntax for declaring a table <literal>WITHOUT OIDS</literal>, creating a table <literal>WITH OIDS</literal> is not supported anymore. これはWITHOUT OIDSのテーブルと宣言する後方互換性の構文です。 WITH OIDSのテーブルを作ることはもはやサポートされません。

The behavior of temporary tables at the end of a transaction block can be controlled using <literal>ON COMMIT</literal>. The three options are: ON COMMITを使用して、トランザクションブロックの終了時点での一時テーブルの動作を制御することができます。 以下の3つのオプションがあります。

The <replaceable class="parameter">tablespace_name</replaceable> is the name of the tablespace in which the new table is to be created. If not specified, <xref linkend="guc-default-tablespace"/> is consulted, or <xref linkend="guc-temp-tablespaces"/> if the table is temporary. For partitioned tables, since no storage is required for the table itself, the tablespace specified overrides <literal>default_tablespace</literal> as the default tablespace to use for any newly created partitions when no other tablespace is explicitly specified. tablespace_nameは、新しいテーブルが作成されるテーブル空間名です。 指定されていない場合、default_tablespaceが、また一時テーブルの場合はtemp_tablespacesが考慮されます。 パーティションテーブルに対しては、そのテーブル自身ではストレージは必要としないため、他のテーブル空間が明示的に指定されていないときに新しく作成されたパーティションに使用するデフォルトのテーブル空間として、指定されたテーブル空間がdefault_tablespaceを上書きします。

This clause allows selection of the tablespace in which the index associated with a <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>, or <literal>EXCLUDE</literal> constraint will be created. If not specified, <xref linkend="guc-default-tablespace"/> is consulted, or <xref linkend="guc-temp-tablespaces"/> if the table is temporary. この句により、UNIQUE、PRIMARY KEY、またはEXCLUDE制約に関連したインデックスを作成するテーブル空間を選択することができます。 指定されていない場合、default_tablespaceが、また一時テーブルであればtemp_tablespacesが考慮されます。