このトピックでは、現在のデータベースに空の新しいテーブルを作成するために使用されるCREATE TABLEステートメントについて説明します。
概要
CREATE TABLEは、現在のデータベースに空の新しいテーブルを作成するために使用されます。 新しいテーブルは、コマンドを発行したアカウントが所有しています。
特定のスキーマに新しいテーブルを作成するには、CREATE TABLE myschema.mytable.... スキーマを指定しない場合、テーブルは現在のスキーマに作成されます。 特別なスキーマに存在するため、一時テーブルを作成するときにスキーマを指定することはできません。 新しいテーブルの名前は、同じスキーマ内の他のテーブル、シーケンス、インデックス、ビュー、または外部テーブルの名前とは異なる必要があります。
CREATE TABLEは、テーブルの行に対応する複合型を表すデータ型を自動的に作成します。 したがって、テーブル名をスキーマ内の既存のデータ型と同じにすることはできません。
オプションの制約句は、挿入または更新操作が成功するために新しい行または更新された行が満たさなければならない制約 (テスト) を課します。 制約は、さまざまな方法でテーブル内の有効な値のセットを定義するのに役立つSQLオブジェクトです。
制約を定義するには、テーブル制約と列制約の2つの方法があります。 列制約は、列定義の一部として定義される。 テーブル制約定義は特定の列に関連付けられておらず、複数の列を含めることができます。 各列制約は、テーブル制約として記述することもできます。 これは、1つの列のみに影響する制約の便利なトークンとして機能します。
テーブルを作成するには、OF句のすべての列タイプまたはタイプに対してUSAGE権限が必要です。
構文
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE [ IF NOT EXISTS ] table_name ( [
{ column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]
| table_constraint
| LIKE source_table [ like_option ... ] }
[, ... ]
] )
[ INHERITS ( parent_table [, ... ] ) ]
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE [ IF NOT EXISTS ] table_name
OF type_name [ (
{ column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
| table_constraint }
[, ... ]
) ]
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE [ IF NOT EXISTS ] table_name
PARTITION OF parent_table [ (
{ column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
| table_constraint }
[, ... ]
) ] { FOR VALUES partition_bound_spec | DEFAULT }
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
where column_constraint is:
[ CONSTRAINT constraint_name ]
{ NOT NULL |
NULL |
CHECK ( expression ) [ NO INHERIT ] |
DEFAULT default_expr |
GENERATED ALWAYS AS ( generation_expr ) STORED |
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ] |
UNIQUE index_parameters |
PRIMARY KEY index_parameters |
REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
[ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) [ NO INHERIT ] |
UNIQUE ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] |
FOREIGN KEY ( column_name [, ... ] ) REFERENCES reftable [ ( refcolumn [, ... ] ) ]
[ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
like_option is:
{ INCLUDING | EXCLUDING } { COMMENTS | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY | INDEXES | STATISTICS | STORAGE | ALL }
partition_bound_spec is:
IN ( partition_bound_expr [, ...] ) |
FROM ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] )
TO ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] ) |
WITH ( MODULUS numeric_literal, REMAINDER numeric_literal )
index_parameters in UNIQUE, PRIMARY KEY, and EXCLUDE constraints are:
[ INCLUDE ( column_name [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) ]
[ USING INDEX TABLESPACE tablespace_name ]
exclude_element in an EXCLUDE constraint is:
{ column_name | ( expression ) } [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ]パラメーター
TEMPORARYまたはTEMP
指定した場合、テーブルは一時テーブルとして作成されます。 一時テーブルはセッションの最後に自動的に削除されるか、現在のトランザクションの最後に削除することもできます (以下のON COMMITを参照) 。 一時テーブルが存在する場合、同じ名前の既存の永続テーブルは現在のセッションには表示されませんが、スキーマ修飾名を使用して参照できます。 一時テーブルに作成されたインデックスは、自動的に一時的です。
自動真空デーモンはアクセスできないため、一時テーブルをクリーニングまたは分析できません。 このため、セッションのSQLコマンドを使用して適切なクリーンアップおよび分析操作を実行する必要があります。 たとえば、一時テーブルを複雑なクエリに使用する場合は、入力後にANALYZEを実行することをお勧めします。
TEMPORARYまたはTEMPの前にGLOBALまたはLOCALを書くことができます。
存在しない場合
同じ名前のリレーションがすでに存在する場合は、エラーをスローしないでください。 メッセージ通知が表示されます。 これは、既存の関係が作成されるテーブルに似ていることを保証するものではないことに注意してください。
table_name
作成するテーブルの名前 (オプションでスキーマで修飾) 。
OF type_name
構造が指定された複合型から取得される型付きテーブルを作成します (名前はオプションでスキーマで修飾できます) 。 型が削除された場合、テーブルも削除されます (DROP typeを使用して) 。 CASCADE) 。
型付きテーブルが作成されると、列のデータ型は基になる複合型によって決まり、CREATE tableコマンドでは指定されません。 ただし、CREATE TABLEコマンドでは、テーブルにデフォルト値と制約を追加したり、ストレージパラメーターを指定したりできます。
column_name
新しいテーブルに作成する列の名前。
data_type
列のデータ型。 これは、配列指定子を含むことができる。
照合COLLATE
COLLATE句は、列に照合順序を割り当てます。この列は、照合可能なデータ型である必要があります。 指定しない場合、列データ型の既定の照合順序が使用されます。
INHERITS (parent_table [, ... ] )
オプションのINHERITS句は、新しいテーブルが自動的にすべての列を継承するテーブルのリストを指定します。 親テーブルは、通常のテーブルまたは外部テーブルにすることができます。
INHERITSを使用すると、新しい子テーブルとその親テーブルの間に永続的な関係が作成されます。 親テーブルへのスキーマ変更は通常、子テーブルにも反映され、デフォルトでは、子テーブルのデータは親テーブルのスキャンに含まれます。
同じ名前の列が複数の親テーブルに存在する場合、親テーブルの各列のデータ型が一致しない限り、エラーが報告されます。 競合がない場合は、重複する列がマージされて、新しいテーブルに1つの列が形成されます。 新しいテーブルの列名のリストに継承された列名が含まれている場合、データ型も継承された列と一致する必要があり、列定義は1つにマージされます。 新しいテーブルで列のデフォルト値が明示的に指定されている場合、このデフォルト値はその列の継承された宣言のデフォルト値よりも優先されます。 それ以外の場合、親テーブルは列に同じデフォルト値を指定する必要があります。そうしないと、エラーが報告されます。
CHECK制約は、基本的に列と同じ方法でマージされます。複数の親テーブルまたは新しいテーブル定義に同じ名前のCHECK制約が含まれている場合、これらの制約はすべて同じチェック式を持つ必要があります。 同じ名前と式の制約は1つのコピーにマージされます。 NO INHERITとしてマークされた親テーブルの制約は考慮されません。 一意の名前が常に選択されるため、新しいテーブルの名前のないCHECK制約はマージされません。
列のSTORAGE設定も親テーブルからコピーされます。
親テーブルの列がID列の場合、このプロパティは継承されません。 必要に応じて、子テーブルの列をID列として宣言できます。
PARTITION BY { RANGE | LIST | HASH } ( {column_name | (式) } [opclass] [, ...] )
オプションのPARTITION BY句は、テーブルをパーティション分割するための戦略を指定します。 作成されたテーブルはパーティションテーブルと呼ばれます。 括弧内の列または式のリストは、テーブルのパーティションキーを形成します。 範囲またはハッシュパーティション分割を使用する場合、パーティションキーに複数の列または式を含めることができます (最大32ですが、この制限はPolarDBの構築時に変更できます) 。 ただし、リストのパーティション分割では、パーティションキーは単一の列または式で構成されている必要があります。
範囲およびリスト分割にはbtree演算子クラスが必要ですが、ハッシュ分割にはハッシュ演算子クラスが必要です。 演算子クラスが明示的に指定されていない場合、対応する型の既定の演算子クラスが使用されます。既定の演算子クラスが存在しない場合、エラーが報告されます。
パーティションテーブルは、個別のCREATE tableコマンドを使用して作成される子テーブル (パーティションと呼ばれます) に分割されます。 パーティションテーブル自体は空です。 テーブルに挿入されて記録されたデータは、パーティションキーの列または式の値に基づいてパーティションにルーティングされます。 新しい行の値と一致する既存のパーティションがない場合、エラーが報告されます。
パーティションテーブルはEXCLUDE制約をサポートしていませんが、これらの制約は個々のパーティションで定義できます。
PARTITION OF parent_table { FOR VALUES partition_bound_spec | DEFAULT }
指定した親テーブルのパーティションとしてテーブルを作成します。 テーブルが作成されたら、FOR VALUESを使用して特定の値のパーティションを作成するか、DEFAULTを使用してデフォルトのパーティションを作成できます。 親テーブルに存在するインデックス、制約、およびユーザー定義の行レベルのトリガーはすべて、新しいパーティションに複製されます。
partition_bound_specは、親テーブルのパーティション分割方法とパーティション分割キーに対応している必要があり、親テーブルの既存のパーティションと重複してはなりません。 INのあるフォームはリスト分割に使用され、FROMとTOのあるフォームは範囲分割に使用され、withのあるフォームはハッシュ分割に使用されます。
partition_bound_exprは、変数なしの式です (サブクエリ、ウィンドウ関数、集計関数、およびset return関数は使用できません) 。 そのデータ型は、対応するパーティションキー列のデータ型と一致する必要があります。 式はテーブルの作成時に一度だけ評価されるため、CURRENT_TIMESTAMPなどの揮発性の式を含めることもできます。
リストパーティションを作成するときに、NULLを指定して、パーティションキー列をnullにすることができます。 しかし、所与の親テーブルは、そのようなリストパーティションを複数有することはできない。 レンジパーティションにはNULLを指定できません。
レンジパーティションを作成する場合、FROMで指定された下限は包括的な境界ですが、TOで指定された上限は排他的な境界です。 つまり、FROMリストで指定された値は、そのパーティションの対応するパーティションキー列の有効な値ですが、TOリストの値は有効ではありません。 このステートメントは、行ごとの比較の規則に従って理解する必要があることに注意してください。 例えば、PARTITION BY RANGE (x,y) が与えられると、パーティション境界FROM (1,2) TO (3,4) は、任意のy>=2でx=1、任意の非ヌルyでx=2、任意のy<4でx=3を許容する。
範囲パーティションを作成するときに、列の値に下限または上限がないことを示す特別な値MINVALUEおよびMAXVALUEを使用できます。 たとえば、FROM (MINVALUE) TO (10) を使用して定義されたパーティションは、10未満の任意の値を許可し、FROM (10) TO (MAXVALUE) を使用して定義されたパーティションは、10以上の任意の値を許可する。
複数の列を含む範囲パーティションを作成する場合、MAXVALUEを下限の一部として、MINVALUEを上限の一部として持つことも意味があります。 例えば、FROM (0, MAXVALUE) TO (10, MAXVALUE) で定義されたパーティションは、第1のパーティションキー列が0より大きく10以下である任意の行を許可する。 同様に、FROM ('a', MINVALUE) TO ('b', MINVALUE) を使用して定義されたパーティションは、第1のパーティションキー列が「a」で始まる任意の行を許可する。
パーティションバインドの1つの列にMINVALUEまたはMAXVALUEを定義する場合、後続のすべての列に同じ値を使用する必要があります。 たとえば、(10, MINVALUE, 0) は有効なバインドではありません。(10, MINVALUE, MINVALUE) を記述する必要があります。
また、timestampなどの一部の要素タイプには、格納可能な別の値である「無限大」の概念があります。 これは、格納できる実際の値ではなく、無限の値を表す方法であるMINVALUEおよびMAXVALUEとは異なります。 MAXVALUEは、任意の他の値 (「無限大」を含む) よりも大きい値と考えることができ、MINVALUEは、任意の他の値 (「マイナス無限大」を含む) よりも小さい値と考えることができる。 したがって、FROM (「無限」) TO (MAXVALUE) の範囲は空の範囲ではなく、1つの値のみを記憶することができ、これは「無限大」である。
DEFAULTが指定されている場合、テーブルは親テーブルのデフォルトパーティションとして作成されます。 このオプションは、ハッシュ分割テーブルには適用されません。 指定された親テーブルの他のパーティションに収まらないパーティションキー値は、既定のパーティションにルーティングされます。
テーブルにすでにDEFAULTパーティションがあり、新しいパーティションを追加する場合は、既定のパーティションをスキャンして、新しいパーティションに属する可能性のある行が含まれていないことを確認する必要があります。 デフォルトのパーティションに多数の行が含まれている場合、スキャンが遅くなる可能性があります。 デフォルトのパーティションが外部テーブルである場合、または新しいパーティションに配置できる行を含む可能性が低いことを証明する制約がある場合、スキャンはスキップされます。
ハッシュパーティションを作成するときは、モジュラスと剰余を指定する必要があります。 モジュラスは正の整数でなければならず、残りはモジュラスより小さい非負の整数でなければならない。 通常、最初にハッシュパーティション分割テーブルを設定するときは、パーティションの数に等しいモジュラスを選択し、各テーブルに同じモジュラスと異なる剰余を割り当てる必要があります (次の例を参照) 。 しかし、すべてのパーティションが同じモジュラスを有する必要はなく、ハッシュパーティションテーブルのパーティション間で発生するすべてのモジュラスが次に大きいモジュラスのファクタであることだけが必要である。 これにより、すべてのデータを一度に移動することなく、パーティションの数を増分的に増やすことができます。 たとえば、それぞれが8のモジュラスを持つ8つのパーティションを持つハッシュパーティションテーブルがあるとしますが、パーティションの数を16に増やす必要があるとします。 modulus-8パーティションの1つをデタッチし、キースペースの同じ部分をカバーする2つの新しいmodulus-16パーティションを作成します (1つはデタッチしたパーティションの剰余に等しい剰余を持ち、もう1つはその値 + 8に等しい剰余を持ちます) 。 その後、残りがなくなるまで、モジュラス8パーティションごとにこのプロセスを繰り返すことができます。 これらのステップのそれぞれは、大量のデータ移動を伴うことがあるが、全く新しいテーブルを作成し、すべてのデータを一度に移動するよりは、依然として優れている。
パーティションは、属するパーティションテーブルと同じ列名とタイプを持つ必要があります。 パーティションテーブルの列名またはタイプに対する変更は、すべてのパーティションに自動的に反映されます。 CHECK制約は各パーティションに自動的に継承されますが、個々のパーティションでは追加のCHECK制約を指定できます。親テーブルと同じ名前と条件を持つ追加の制約は、親テーブル制約によってマージされます。 デフォルトは、パーティションごとに別々に指定することができる。 ただし、パーティションテーブルにタプルを挿入するときは、パーティションのデフォルト値は適用されません。
パーティションテーブルに挿入されたレコードは、自動的に正しいパーティションにルーティングされます。 適切なパーティションが存在しない場合、エラーが発生します。
TRUNCATEのような操作は通常、テーブルとそのすべての継承子に影響します。 これらの操作はすべてのパーティションにカスケード接続されますが、単一のパーティションで実行することもできます。 DROP TABLEを使用してパーティションを削除するには、親テーブルに対するACCESS EXCLUSIVEロックが必要です。
LIKE source_table [like_option... ]
新しいテーブルがすべての列名、データ型、およびそれらの非null制約を自動的にレプリケートするテーブルを指定します。
INHERITSとは異なり、新しいテーブルは作成後に元のテーブルから完全に分離されます。 元のテーブルへの変更は新しいテーブルに適用されず、元のテーブルのスキャンに新しいテーブルのデータを含めることはできません。
また、INHERITSとは異なり、LIKEでコピーされた列と制約は、同じ名前の列と制約とマージされません。 同じ名前が明示的に指定されている場合、または別のLIKE句で同じ名前が指定されている場合、エラーが報告されます。
オプションのlike_option句は、コピーする元のテーブルの追加プロパティを指定します。 プロパティをコピーするにはINCLUDINGを、プロパティを省略するにはEXCLUDINGを指定します。 EXCLUDINGはデフォルト値です。 同じ型のオブジェクトに対して複数の仕様が指定されている場合は、最後の仕様が使用されます。 利用可能なオプションは次のとおりです。
コメントを含む
コピーされた列、制約、およびインデックスのコメントがコピーされます。 既定の動作では、コメントを除外し、列と制約がコメントなしで新しいテーブルにコピーされます。
コンストレイントを含む
CHECK制約がコピーされます。 列制約とテーブル制約の間に違いはありません。 nullでない制約は常に新しいテーブルにコピーされます。
デフォルトを含む
コピーされた列に定義されている既定の式がコピーされます。 それ以外の場合、既定の式はコピーされず、新しいテーブルのコピーされた列の既定値はnullになります。 nextvalなどのデータベース変更関数を呼び出すデフォルトをコピーすると、元のテーブルと新しいテーブルの間に機能的なリンクが作成される場合があることに注意してください。
生成されたもの
コピーされた列定義の世代式はすべてコピーされます。 デフォルトでは、新しい列は通常のベース列になります。
アイデンティティを含む
コピーされた列定義のID仕様はコピーされます。 新しいシーケンスは、古いテーブルに関連付けられたシーケンスとは別に、新しいテーブルの各識別列に対して作成されます。
インデックスを含む
元のテーブルのインデックス、PRIMARY KEY、UNIQUE、およびEXCLUDE制約が新しいテーブルに作成されます。 新しいインデックスと制約の名前は、元の名前に関係なく、デフォルトのルールに従って選択されます。 (この動作は、新しいインデックスの重複名の失敗の可能性を回避します。)
統計を含む
拡張統計は新しいテーブルにコピーされます。
ストレージを含む
コピーした列定義のSTORAGE設定がコピーされます。 既定の動作では、STORAGE設定を除外します。これにより、新しいテーブルの列がタイプ固有のデフォルト設定を持つようになります。
すべてを含む
使用可能なすべての個々のオプションを選択する省略形。 (INCLUDING ALLの後に個々のEXCLUDING句を記述して、特定のオプションを除くすべてを選択するために使用できます。)
LIKE句は、ビュー、外部テーブル、または複合型から列定義をコピーするためにも使用できます。 ビューからのINCLUDING INDEXESなどの適用できないオプションは無視されます。
CONSTRAINT constraint_name
列またはテーブル制約のオプションの名前。 制約に違反すると、制約名がエラーメッセージに表示されるため、col must be positiveのような制約名を使用して、有用な制約情報をクライアントアプリケーションに伝えることができます。 (スペースを含む制約名を指定するには、二重引用符が必要です。) 制約名が指定されていない場合、システムは名前を生成します。
NOT NULL
列に null 値を含めることを許可しません。
NULL
列にnull値を含めることができます。 この値がデフォルトです。
この句は、非標準SQLデータベースとの互換性のためにのみ提供されます。 その使用は、新しいアプリケーションでは推奨されません。
CHECK (式) [ NO INHERIT ]
CHECK句は、挿入または更新操作が成功するために新しい行または更新された行が満たす必要があるブール結果を生成する式を指定します。 TRUEまたはUNKNOWNに評価する式は成功します。 挿入または更新操作のいずれかの行がFALSE結果を生成した場合、エラー例外が発生し、挿入または更新によってデータベースが変更されることはありません。 列制約として指定されたチェック制約はその列の値のみを参照する必要がありますが、テーブル制約に表示される式は複数の列を参照できます。
現在、CHECK式にサブクエリを含めることも、現在の行の列以外の変数を参照することもできません。システム列tableoidは参照できますが、他のシステム列は参照できません。
NO INHERITでマークされた制約は、子テーブルに伝播しません。
テーブルに複数のCHECK制約がある場合、NOT NULL制約をチェックした後、名前のアルファベット順に行ごとにテストされます。
DEFAULT default_expr
DEFAULT句は、列定義が表示される列に既定のデータ値を割り当てます。 値は変数のない式です (特に、現在のテーブルの他の列への相互参照は許可されません) 。 サブクエリも許可されていません。 デフォルトの式のデータ型は、列のデータ型と一致する必要があります。
デフォルトの式は、列の値を指定しない挿入操作で使用されます。 列にデフォルトがない場合、デフォルトはnullです。
ジェネレーテッド常にAS (generation_expr) STORED
この句は、列を生成列として作成します。 列を書き込むことはできず、読み取ると、指定された式の結果が返されます。
キーワードSTOREDは、列が書き込み時に計算され、ディスクに格納されることを示すために必要です。
生成式は、テーブル内の他の列を参照できますが、他の生成された列は参照できません。 使用する関数と演算子はすべて不変である必要があります。 他のテーブルへの参照は許可されません。
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ (sequence_options) ]
この句は、列をID列として作成します。 暗黙的なシーケンスがアタッチされ、新しい行の列にはシーケンスの値が自動的に割り当てられます。
ALWAYSおよびBY DEFAULT句は、INSERTおよびUPDATEコマンドでユーザー指定の値を明示的に処理する方法を決定します。
INSERTコマンドで、ALWAYSが選択されている場合、INSERTステートメントでOVERRIDING SYSTEM valueが指定されている場合にのみ、ユーザー指定の値が受け入れられます。 BY DEFAULTが選択されている場合、ユーザー指定の値が優先されます。 (COPYコマンドでは、この設定に関係なく、常にユーザー指定の値が使用されます。)
UPDATEコマンドで、ALWAYSを選択した場合、DEFAULT以外の値への列の更新は拒否されます。 BY DEFAULTを選択した場合、列は正常に更新できます。 (UPDATEコマンドにはOVERRIDING句はありません。)
オプションのsequence_options句を使用して、シーケンスのオプションをオーバーライドできます。 詳細については、「CREATE SEQUENCE」をご参照ください。
UNIQUE (列制約)
UNIQUE (colume_name [, ... ] ) [INCLUDE (colume_name [, ...]) ] (テーブル制約)
UNIQUE制約は、テーブルの1つ以上の列のグループに一意の値のみを含めることができることを指定します。 一意のテーブル制約の動作は、列制約の動作と同じですが、複数の列にまたがる機能が追加されています。
一意の制約のために、ヌル値は等しいとはみなされない。
各一意制約は、テーブルに対して定義された他の一意または主キー制約によって名前が付けられた列のセットとは異なる列のセットに名前を付ける必要があります。 (そうでなければ、冗長な一意の制約は破棄される。)
複数レベルのパーティション階層に一意の制約を設定する場合、ターゲットのパーティション分割テーブルのパーティションキーのすべての列と、そのすべての子孫のパーティション分割テーブルの列を、制約定義に含める必要があります。
一意の制約を追加すると、制約で使用される列または列のグループに一意のbtreeインデックスが自動的に作成されます。 otional INCLUDE句は、一意性の強制なしに、そのインデックスに1つ以上の列を追加します。 制約は含まれる列に適用されませんが、それでもそれらに依存することに注意してください。 その結果、そのような列に対するいくつかの操作 (例えば、DROP COLUMN) は、カスケード制約およびインデックス削除を引き起こし得る。
PRIMARY KEY (列制約)
PRIMARY KEY ([, ... ]] [INCLUDE (colume_name)colume_name [, ...]) ] (テーブル制約)
PRIMARY KEY制約は、テーブルの1つまたは複数の列に一意 (重複しない) のnull以外の値のみを含めることができることを指定します。 列制約またはテーブル制約どちらにおいても、テーブルに指定できる主キーは 1 つだけです。
主キー制約は、同じテーブルに対して定義された一意の制約によって名前が付けられた列のセットとは異なる列のセットに名前を付ける必要があります。 (それ以外の場合、一意の制約は冗長であり、破棄されます。)
PRIMARY KEYは、UNIQUEとNOT NULLの組み合わせと同じデータ制約を適用します。 しかし、主キーとして列のセットを識別することは、スキーマの設計に関するメタデータも提供する。なぜなら、主キーは、他のテーブルが、行の一意の識別子としてこの列のセットに依存できることを意味するからである。
パーティション化されたテーブルに配置されると、PRIMARY KEY制約は、UNIQUE制約について前述した制約を共有します。
PRIMARY KEY制約を追加すると、制約で使用される列または列グループに一意のbtreeインデックスが自動的に作成されます。 オプションのINCLUDE句を使用すると、インデックスの非キー部分に含まれる列のリストを指定できます。 一意性は含まれる列に適用されませんが、制約は依然としてそれらに依存します。 その結果、そのような列に対するいくつかの操作 (例えば、DROP COLUMN) は、カスケード制約およびインデックス削除を引き起こし得る。
EXCLUDE [ USING index_method] (WITH演算子 exclude_element [, ... ] ) index_parameters [ WHERE (述語) ]
EXCLUDE句は、指定された演算子を使用して指定された列または式で任意の2つの行を比較した場合、すべての比較がTRUEを返さないことを保証する除外制約を定義します。 指定されたすべての演算子が等しいかどうかをテストする場合、これはUNIQUE制約と同等ですが、通常の一意の制約はより高速になります。 ただし、除外制約は、単純な等式よりも一般的な制約を指定できます。 たとえば、&& 演算子を使用して、テーブル内の2つの行に重複する円が含まれないように制約を指定できます。
除外制約はインデックスを使用して実装されるため、指定された各演算子は、インデックスアクセスメソッドindex_methodの適切な演算子クラスに関連付ける必要があります。 演算子は可換である必要があります。 各exclude_要素はインデックスの列を定義するため、照合順序、演算子クラス、演算子クラスパラメータ、および /または順序付けオプションをオプションで指定できます。 詳細については、「CREATE INDEX」をご参照ください。
アクセスメソッドはamgettupleをサポートする必要があります。 許可されていますが、除外制約付きのBツリーまたはハッシュインデックスを使用することにはほとんど意味がありません。これは、通常の一意の制約よりも優れているためです。 したがって、実際には、アクセス方法は常にGiSTまたはSP-GiSTである。
述語を使用すると、テーブルのサブセットに除外制約を指定できます。これにより、内部的に部分インデックスが作成されます。 述語の周りには括弧が必要です。
参考文献 reftable [( refcolumn ) ] [[マッチ マッチタイプ ] [削除中 referential_action ] [更新中 referential_action ](列制約)
外国のキー ( column_name [, ... ] ) 参考文献 reftable [( refcolumn [, ... ] ) ] [マッチ] マッチタイプ ] [削除中 referential_action ] [更新中 referential_action ](テーブル制約)
これらの句は、外部キー制約を指定します。これは、新しいテーブルの1つ以上の列のグループが、参照されるテーブルのある行の参照される列の値と一致する値のみを含む必要があることを要求します。 refcolumnリストを省略すると、reftableの主キーが使用されます。 参照される列は、参照されるテーブルの延期できない一意の制約または主キーの制約である必要があります。 ユーザーは、参照先テーブル (テーブル全体または特定の参照先列) に対するREFERENCES権限を持っている必要があります。 外部キー制約の追加には、参照されるテーブルに対するSHARE ROW EXCLUSIVEロックが必要です。 一時テーブルと永続テーブルの間に外部キー制約を定義することはできません。
参照元の列に挿入された値は、指定された一致型を使用して、参照先のテーブルと参照先の列の値と照合されます。 match FULL、MATCH PARTIAL、MATCH SIMPLE (デフォルト) の3つのマッチタイプがあります。 MATCH FULLでは、すべての外部キー列がnullでない限り、複数列の外部キーの1つの列をnullにすることはできません。 MATCH SIMPLEでは、外部キー列のいずれかをnullにすることができます。これらの列のいずれかがnullの場合、その行は参照テーブルで一致する必要はありません。 MATCH PARTIALはまだ実装されていません。 (もちろん、これらのケースが発生するのを防ぐために、参照列にNOT NULL制約を適用できます) 。
さらに、参照される列のデータが変更されると、このテーブルの列のデータに対して特定のアクションが実行されます。 ON DELETE句は、参照テーブルの参照行が削除されているときに実行するアクションを指定します。 同様に、ON UPDATE句は、参照テーブルの参照列が新しい値に更新されたときに実行するアクションを指定します。 行が更新されても、参照される列が実際に変更されていない場合、アクションは実行されません。 制約が延期可能と宣言されていても、NO ACTIONチェック以外の参照アクションは延期できません。 各句には次のアクションが考えられます。
ノーアクション
削除または更新によって外部キー制約違反が発生することを示すエラーを生成します。 制約が延期されている場合、参照行がまだ存在する場合、このエラーは制約チェック時に生成されます。 これはデフォルトのアクションです。
制限
削除または更新によって外部キー制約違反が発生することを示すエラーを生成します。 これは、チェックが延期できないことを除いて、NO ACTIONと同じです。
カスケード
削除された行を参照する行を削除するか、参照先の列の値を参照先の列の新しい値にそれぞれ更新します。
SET NULL
すべての参照列をnullに設定します。
セットデフォルト
すべての参照列をデフォルト値に設定します。 (デフォルト値がnullでない場合、参照テーブルにはデフォルト値と一致する行が必要です。そうしないと、操作が失敗します。)
参照される列が頻繁に変更される場合、外部キー制約に関連付けられた参照アクションをより効率的に実行できるように、参照する列にインデックスを追加することが賢明である場合があります。
卑劣な卑劣な
この句は、制約を延期できるかどうかを制御します。 延期できない制約は、各コマンドの直後にチェックされます。 延期可能な制約のチェックは、(SET constraintsコマンドを使用して) トランザクションの終了まで延期される。 NOT DEFERRABLEがデフォルトです。 現在、UNIQUE、PRIMARY KEY、EXCLUDE、およびREFERENCES (外部キー) 制約のみがこの句を受け入れます。 NOT NULLおよびCHECK制約は延期できません。 延期可能な制約は、ON conflict DO UPDATE句を含むINSERTステートメントで競合アービトレータとして使用できないことに注意してください。
初期に即時初期に非難
制約が DEFERRABLE (延期可能) である場合、この句は制約をチェックするデフォルトの時間を指定します。 制約がINITIALLY IMMEDIATEの場合、各ステートメントの後にチェックされます。 この値がデフォルトです。 制約がINITIALLY DEFERREDの場合、トランザクションの最後にのみチェックされます。 制約チェック時間は、SET CONSTRAINTSコマンドで変更できます。
メソッドを使用
このオプションの句は、新しいテーブルの内容を格納するために使用されるテーブルアクセスメソッドを指定します。このメソッドには、table型のアクセスメソッドが必要です。 このオプションを指定しない場合、新しいテーブルにはデフォルトのテーブルアクセス方法が選択されます。
WITH (storage_parameter [= value] [, ... ] )
この句は、テーブルまたはインデックスのオプションのストレージパラメーターを指定します。 詳細については、このトピックのストレージパラメーターのセクションを参照してください。 下位互換性のために、テーブルのWITH句にOIDS=FALSEを含めて、新しいテーブルの行にOID (オブジェクト識別子) を含まないように指定することもできます。 OIDS=TRUEはサポートされなくなりました。
子供なし
これは、OIDSなしでテーブルを宣言するための下位互換性のある構文です。 WITH OIDSテーブルの作成はサポートされなくなりました。
コミット中
トランザクションブロックの最後にある一時テーブルの動作は、ON COMMITを使用して制御できます。 3つのオプションは次のとおりです。
PRESERVE ROWS
トランザクションの最後に特別なアクションは取られません。 これはデフォルトの動作です。
DELETE ROWS
一時テーブルのすべての行は、各トランザクションブロックの最後に削除されます。 本質的に、自動TRUNCATEは各コミットで行われる。 パーティションテーブルで使用される場合、これはそのパーティションにカスケードされません。
ドロップ
一時テーブルは、現在のトランザクションブロックの最後に削除されます。 パーティションテーブルで使用すると、このアクションはパーティションを削除し、継承子を持つテーブルで使用すると、依存子を削除します。
TABLESPACE tablespace_name
tablespace_nameは、新しいテーブルが作成されるテーブルスペースの名前です。 指定しない場合、default_tablespaceが参照され、テーブルが一時的な場合はtemp_tablespacesが参照されます。 パーティションテーブルの場合、テーブル自体にストレージは必要ないため、他のテーブルスペースが明示的に指定されていない場合、指定されたテーブルスペースは、新しく作成されたパーティションのデフォルトのテーブルスペースとしてdefault_tablespaceを上書きします。
インデックスTABLESPACE tablespace_nameの使用
この句では、UNIQUE、PRIMARY KEY、またはEXCLUDE制約に関連付けられたインデックスが作成されるテーブルスペースを選択できます。 指定しない場合、default_tablespaceが参照され、テーブルが一時的な場合はtemp_tablespacesが参照されます。
ストレージパラメータ
WITH句は、テーブル、およびUNIQUE、PRIMARY KEY、またはEXCLUDE制約に関連付けられたインデックスのストレージパラメーターを指定できます。 インデックスのストレージパラメーターは、CREATE INDEXに記載されています。 テーブルで現在使用できるストレージパラメーターを以下に示します。 これらのパラメーターの多くには、図のように、同じ名前の接頭辞が付いた追加のパラメーターがあります。トースト。これは、テーブルのセカンダリTOASTテーブル (存在する場合) の動作を制御します。 テーブルパラメータ値が設定されているが、対応するトースト。 パラメーターが設定されていない場合、TOASTテーブルはテーブルのパラメーター値を使用します。 これらのパラメーターはパーティションテーブルには指定できませんが、個々のリーフパーティションには指定できます。
fillfactor (integer)
テーブルのfillfactorは、10〜100のパーセンテージです。 100 (完全なパッキング) はデフォルトです。 より小さいfillfactorが指定されている場合、INSERT操作はテーブルページを指定された割合にのみパックします。 各ページの残りのスペースは、そのページの行を更新するために予約されます。 これにより、UPDATEは、更新された行のコピーを元のページと同じページに配置することができます。これは、別のページに配置するよりも効率的です。 エントリが更新されないテーブルでは、完全なパッキングが最良の選択ですが、大幅に更新されたテーブルでは、より小さなフィルファクタが適切です。 このパラメーターはTOASTテーブルには設定できません。
toast_tuple_target (integer)
長い列値を圧縮および /またはTOASTテーブルに移動しようとする前に、toast_tuple_targetは必要な最小タプル長を指定します。 これは、外部 (移動の場合) 、メイン (圧縮の場合) 、または拡張 (両方の場合) としてマークされた列に影響し、新しいタプルにのみ適用されます。 既存の行には影響がありません。 デフォルトでは、このパラメータはブロックごとに少なくとも4つのタプルを許可するように設定されています。デフォルトのブロックサイズは2040バイトです。 有効な値は、128バイトと (ブロックサイズ-ヘッダー) の間ですが、デフォルトでは8160バイトです。 この値を変更すると、非常に短い行または非常に長い行には役に立たない場合があります。 デフォルト設定は最適に近いことが多く、このパラメーターを設定すると、場合によっては悪影響が生じる可能性があることに注意してください。 このパラメーターはTOASTテーブルには設定できません。
parallel_workers (integer)
このパラメーターは、このテーブルの並列スキャンを支援するために使用されるワーカーの数を設定します。 設定されていない場合、システムは関係サイズに基づいて値を決定します。 プランナーまたは並列スキャンを使用するユーティリティステートメントによって選択されるワーカーの実際の数は、max_worker_processesの設定などにより少なくなる場合があります。
autovacuum_enabled, toast.autovacuum_enabled (boolean)
特定のテーブルの自動真空デーモンを有効または無効にします。 trueの場合、自動真空デーモンはこのテーブルに対して自動VACUUMおよび /またはANALYZE操作を実行します。 falseの場合、トランザクションIDのラップアラウンドを防ぐことを除いて、このテーブルは自動掃除されません。 自動真空パラメーターがfalseの場合、自動真空デーモンはまったく実行されません (トランザクションIDのラップアラウンドを防ぐためを除く) 。個々のテーブルのストレージパラメーターを設定しても、それは無効になりません。 したがって、このストレージパラメータを明示的にtrueに設定し、falseに設定することはめったにありません。
vacuum_index_cleanup, toast.vacuum_index_cleanup (boolean)
このテーブルでVACUUMを実行すると、インデックスのクリーンアップを強制または無効にします。 デフォルト値はtrueです。 すべてのインデックスクリーンアップを強制的に無効にすると、VACUUMが大幅に高速化されますが、テーブルの変更が頻繁に行われると、インデックスがひどく肥大化する可能性があります。 VACUUMのINDEX_CLEANUPパラメーターを指定すると、このオプションの値がオーバーライドされます。
vacuum_truncate, toast.vacuum_truncate (boolean)
vacuumを有効または無効にして、このテーブルの最後にある空のページを切り捨てることを試みます。 デフォルト値は true です。 trueの場合、VACUUMと自動真空は切り捨てを実行し、切り捨てられたページのディスク領域がオペレーティングシステムに返されます。 切り捨てには、テーブルに対するACCESS EXCLUSIVEロックが必要です。 VACUUMのTRUNCATEパラメーターを指定すると、このオプションの値がオーバーライドされます。
autovacuum_vacuum_threshold, toast.autovacuum_vacuum_threshold (integer)
テーブルでVACUUMをトリガーできる、挿入、更新、または削除されたタプルの最小数を指定します。 デフォルト値は50です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_vacuum_scale_factor, toast.autovacuum_vacuum_scale_factor (浮動小数点)
VACUUMをトリガーするかどうかを決定するときにautovacum_vacuum_thresholdに追加されるテーブルサイズの一部を指定します。デフォルトは0.2 (テーブルサイズの20%) です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_vacuum_insert_threshold, toast.autovacuum_vacuum_insert_threshold (整数)
任意の1つのテーブルでVACUUM操作をトリガーするために必要な挿入タプルの数を指定します。 デフォルト値は1000タプルです。 -1が指定されている場合、autovacuumは挿入数に基づいてどのテーブルに対してもVACUUM操作をトリガーしません。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できますが、テーブルのストレージパラメーターを変更することで、個々のテーブルに対して設定をオーバーライドできます。
autovacuum_vacuum_insert_scale_factor, toast.autovacuum_vacuum_insert_scale_factor (float4)
VACUUM操作をトリガーするかどうかを決定するときに、autovacuum_vacuum_insert_thresholdに追加するサイズの一部を指定します。 デフォルトは0.2 (テーブルサイズの20%) です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できますが、テーブルのストレージパラメーターを変更することで、個々のテーブルに対して設定をオーバーライドできます。
autovacum_analyze_threshold (integer)
テーブルでANALYZE操作をトリガーできる、挿入、更新、または削除されたタプルの最小数を指定します。 デフォルト値は50です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_analyze_scale_factor (浮動小数点)
ANALYZE操作をトリガーするかどうかを決定するときに、autovacuum_analyze_thresholdに追加するテーブルサイズの一部を指定します。 デフォルト値は0.1 (テーブルサイズの10%) です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_vacuum_cost_delay, toast.autovacuum_vacuum_cost_delay (浮動小数点)
自動VACUUM操作で使用するコスト遅延値を指定します。 -1 (デフォルト) を指定すると、vacuum_cost_delay値が使用されます。 この値を単位なしで指定した場合は、ミリ秒となります。 デフォルト値は2ミリ秒です。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_vacuum_cost_limit, toast.autovacuum_vacuum_cost_limit (整数)
自動VACUUM操作で使用するコスト制限値を指定します。 -1 (デフォルト) を指定した場合, vacuum_cost_limitパラメーターの値が使用されます。 複数の自動真空ワーカーが存在する場合、この値は実行中の自動真空ワーカーに比例して分配されます。 したがって、各ワーカーの制限の合計は、このパラメーターの値を超えません。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定をオーバーライドできます。
autovacuum_freeze_min_age, toast.autovacuum_freeze_min_age (整数)
VACUUMが、古いXIDを持つページのフリーズをトリガーするかどうかを判断するために使用するカットオフ期間 (トランザクション内) を指定します。 デフォルト値は5百万トランザクションです。 ユーザーはこの値を0から10億に設定できますが、VACUUMは有効値をautovacuum_freeze_max_ageの値の半分に静かに制限します。 システム全体のautovacuum_freeze_max_age設定の半分を超える、テーブル固有のautovacuum_freeze_min_ageは無視されます。
autovacuum_freeze_max_age, toast.autovacuum_freeze_max_age (整数)
テーブル内のトランザクションIDのラップアラウンドを防ぐためにVACUUM操作が強制される前に、テーブルのpg_class.relfrozenxidフィールドが到達できる最大期間 (トランザクション単位) を指定します。 自動真空が無効になっている場合でも、システムはラップアラウンドを防ぐために自動クリーンアッププロセスを開始します。
Vacuumはpg_xactサブディレクトリから古いファイルを削除することもできます。そのため、デフォルトでは200万件のトランザクションが比較的少なくなります。 このパラメーターはサーバーの起動時にのみ設定できますが、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定を減らすことができます。
autovacuum_freeze_table_age, toast.autovacuum_freeze_table_age (整数)
VACUUMは、テーブルのpg_class.relfrozenxidフィールドがこの設定で指定された年齢に達すると、積極的なスキャンを実行します。 アグレッシブスキャンは、デッドタプルを含むページだけでなく、凍結されていないXIDまたはMXIDを含むすべてのページにアクセスするという点で、通常のVACUUMとは異なります。 デフォルトは150万トランザクションです。 ユーザーはこの値を0〜20億の範囲で設定できますが、VACUUMは有効値をautovacuum_freeze_max_ageの95% に制限するため、定期的な手動VACUUMは、テーブルのラップアラウンド防止自動真空が開始される前に実行する機会があります。
autovacuum_multixact_freeze_min_age, toast.autovacuum_multixact_freeze_min_age (integer)
古いmultixact IDを持つページのフリーズをトリガーするかどうかを決定するためにVACUUMが使用するカットオフ年齢 (multixact) を指定します。 デフォルト値は5 million multiactsです。 ユーザーはこの値を0〜10億の範囲で設定できますが、VACUUMは有効値をautovacuum_multixact_freeze_max_ageの値の半分に制限します。 注自動真空は、システム全体の設定の半分を超えるテーブル固有のautovacuum_multixact_freeze_max_ageを無視します。
autovacuum_multixact_freeze_max_age, toast.autovacuum_multixact_freeze_max_age (integer)
テーブル内のトランザクションIDのラップアラウンドを防ぐためにVACUUM操作が強制される前に、テーブルのpg_class.relfrozenxidフィールドが到達できる最大期間 (トランザクション単位) を指定します。 自動真空が無効になっている場合でも、システムはラップアラウンドを防ぐために自動クリーンアッププロセスを開始します。
Vacuumはpg_xactサブディレクトリから古いファイルを削除することもできます。そのため、デフォルトでは200万件のトランザクションが比較的少なくなります。 このパラメーターはサーバーの起動時にのみ設定できますが、テーブルのストレージパラメーターを変更することで、個々のテーブルの設定を減らすことができます。 autovacuum_multixact_freeze_max_age: autovacuum_multixact_freeze_max_ageパラメーターのテーブルごとの値。 自動真空は、システム全体の設定よりも大きいテーブルごとのautovacuum_multixact_freeze_max_ageパラメーターを無視することに注意してください (小さく設定することしかできません) 。
autovacuum_multixact_freeze_table_age, toast.autovacuum_multixact_freeze_table_age (integer)
VACUUMは、テーブルのpg_class.relminmxidフィールドがこの設定で指定された年齢に達すると、積極的なスキャンを実行します。 アグレッシブスキャンは通常のスキャンとは異なり、デッドタプルを含む可能性のあるページをスキャンするだけでなく、凍結されていないXIDまたはMXIDを含む可能性のあるすべてのページにアクセスします。 デフォルトは150億multixactsです。 ユーザーはこの値を0〜20億の範囲で設定できますが、VACUUMは有効値をautovacuum_multixact_freeze_max_age値の95% に静かに設定します。
log_autovacuum_min_duration, toast.log_autovacuum_min_duration (整数)
指定された時間以上実行された場合、自動真空によって実行された各アクションがログに記録されます。 このパラメーターを0に設定すると、すべての自動真空操作が記録されます。 -1 (デフォルト) は自動真空操作のロギングを無効にします。 この値を単位なしで指定した場合は、ミリ秒となります。 たとえば、250ミリ秒に設定すると、250ミリ秒以上実行されたすべての自動真空と分析がログに記録されます。 さらに、このパラメーターが-1以外の値に設定されている場合、競合するロックまたは同時にドロップされた関係のために自動真空アクションがスキップされた場合、メッセージはログに記録されます。 このパラメータは、自動真空アクティビティの追跡に役立ちます。 このパラメーターは、postgresql.confファイルまたはサーバーのコマンドラインでのみ設定できます。 ただし、この設定は、テーブルのストレージパラメーターを変更することで、個々のテーブルに対してオーバーライドできます。
user_catalog_table (boolean)
論理レプリケーションのために、テーブルを追加のカタログテーブルとして宣言します。 このパラメーターはTOASTテーブルには設定できません。
ノート
PolarDBは、一意性を強制するために、一意の制約と主キー制約ごとにインデックスを作成します。 したがって、主キー列のインデックスを明示的に作成する必要はありません。
現在の実装では、一意の制約と主キーは継承されません。 これにより、継承と固有の制約の組み合わせがむしろ機能不全になります。
テーブルに1600を超える列を含めることはできません。 (実際には、有効限界は通常、タプル長の制約のために低くなります。)
例
テーブルフィルムとテーブルディストリビューターを作成する:
CREATE TABLE films (
code char(5) CONSTRAINT firstkey PRIMARY KEY,
title varchar(40) NOT NULL,
did integer NOT NULL,
date_prod date,
kind varchar(10),
len interval hour to minute
);
CREATE TABLE distributors (
did integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
name varchar(40) NOT NULL CHECK (name <> '')
);2次元配列を持つテーブルを作成する:
CREATE TABLE array_int (
vector int[][]
);テーブルフィルムに一意のテーブル制約を定義します。 テーブルの1つ以上の列で一意のテーブル制約を定義できます。
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT production UNIQUE(date_prod)
);チェックの列制約を定義します。
CREATE TABLE distributors (
did integer CHECK (did > 100),
name varchar(40)
);チェックのテーブル制約を定義します。
CREATE TABLE distributors (
did integer,
name varchar(40),
CONSTRAINT con1 CHECK (did > 100 AND name <> '')
);テーブルフィルムの主キーテーブル制約を定義します。
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT code_title PRIMARY KEY(code,title)
);テーブルディストリビューターの主キー制約を定義します。 次の2つの例は同等です。1つ目はテーブル制約構文を使用し、2つ目は列制約構文を使用します。
CREATE TABLE distributors (
did integer,
name varchar(40),
PRIMARY KEY(did)
);
CREATE TABLE distributors (
did integer PRIMARY KEY,
name varchar(40)
);列名にリテラル定数のデフォルト値を割り当て、シーケンスオブジェクトの次の値を選択してcolumn didのデフォルト値を生成するように配置し、modtimeのデフォルト値を行が挿入された時刻にします。
CREATE TABLE distributors (
name varchar(40) DEFAULT 'Luso Films',
did integer DEFAULT nextval('distributors_serial'),
modtime timestamp DEFAULT current_timestamp
);テーブルディストリビューターに対して2つのNOT NULL列制約を定義します。そのうちの1つには明示的に名前が付けられます。
CREATE TABLE distributors (
did integer CONSTRAINT no_null NOT NULL,
name varchar(40) NOT NULL
);name列に一意の制約を定義します。
CREATE TABLE distributors (
did integer,
name varchar(40) UNIQUE
);同じ一意の制約がテーブル制約で指定されます。
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name)
);同じテーブルを作成し、テーブルとその一意のインデックスの両方に70% fill factorを指定します。
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name) WITH (fillfactor=70)
)
WITH (fillfactor=70);2つの円が重ならないようにする除外制約を持つテーブル円を作成します。
CREATE TABLE circles (
c circle,
EXCLUDE USING gist (c WITH &&)
);テーブルスペースdiskvol1にテーブルシネマを作成します。
CREATE TABLE cinemas (
id serial,
name text,
location text
) TABLESPACE diskvol1;複合型と型付きテーブルを作成します。
CREATE TYPE employee_type AS (name text, salary numeric);
CREATE TABLE employees OF employee_type (
PRIMARY KEY (name),
salary WITH OPTIONS DEFAULT 1000
);範囲パーティション分割テーブルを作成する:
CREATE TABLE measurement (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);パーティションキーに複数の列を持つレンジパーティションテーブルを作成します。
CREATE TABLE measurement_year_month (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (EXTRACT(YEAR FROM logdate), EXTRACT(MONTH FROM logdate));リスト分割テーブルを作成する:
CREATE TABLE cities (
city_id bigserial not null,
name text not null,
population bigint
) PARTITION BY LIST (left(lower(name), 1));ハッシュ分割テーブルを作成する:
CREATE TABLE orders (
order_id bigint not null,
cust_id bigint not null,
status text
) PARTITION BY HASH (order_id);レンジパーティションテーブルのパーティションを作成する:
CREATE TABLE measurement_y2016m07
PARTITION OF measurement (
unitsales DEFAULT 0
) FOR VALUES FROM ('2016-07-01') TO ('2016-08-01');パーティションキーに複数の列を持つレンジパーティションテーブルのパーティションをいくつか作成します。
CREATE TABLE measurement_ym_older
PARTITION OF measurement_year_month
FOR VALUES FROM (MINVALUE, MINVALUE) TO (2016, 11);
CREATE TABLE measurement_ym_y2016m11
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 11) TO (2016, 12);
CREATE TABLE measurement_ym_y2016m12
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 12) TO (2017, 01);
CREATE TABLE measurement_ym_y2017m01
PARTITION OF measurement_year_month
FOR VALUES FROM (2017, 01) TO (2017, 02);リストパーティションテーブルのパーティションを作成する:
CREATE TABLE cities_ab
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b');さらにパーティション分割されたリストパーティションテーブルのパーティションを作成し、パーティションを追加します。
CREATE TABLE cities_ab
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b') PARTITION BY RANGE (population);
CREATE TABLE cities_ab_10000_to_100000
PARTITION OF cities_ab FOR VALUES FROM (10000) TO (100000);ハッシュパーティションテーブルのパーティションを作成する:
CREATE TABLE orders_p1 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE orders_p2 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE orders_p3 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE orders_p4 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 3);デフォルトのパーティションを作成する:
CREATE TABLE cities_partdef
PARTITION OF cities DEFAULT;互換性
CREATE TABLEコマンドは、以下の例外を除いて、SQL標準に準拠しています。
一時テーブル
CREATE TEMPORARY TABLEの構文はSQL標準の構文に似ていますが、効果は同じではありません。 標準では、一時テーブルは1回だけ定義され、それらを必要とするすべてのセッションで自動的に存在します (空の内容から始まります) 。 代わりに、PolarDBでは、各セッションが、使用する各一時テーブルに対して独自のCREATE TEMPORARY TABLEコマンドを発行する必要があります。 これにより、異なるセッションが異なる目的で同じ一時テーブル名を使用できるようになりますが、標準のアプローチでは、特定の一時テーブル名のすべてのインスタンスが同じテーブル構造を持つように制限されます。
一時テーブルの動作に関する標準の定義は、広く無視されています。 この点でのPolarDBの動作は、他のいくつかのSQLデータベースの動作と似ています。
SQL標準では、グローバル一時テーブルとローカル一時テーブルも区別されます。ローカル一時テーブルには、各セッション内のSQLモジュールごとに個別のコンテンツセットがありますが、その定義はセッション間で共有されます。 PolarDBはSQLモジュールをサポートしていないため、この区別はPolarDBには関係ありません。
互換性のために、PolarDBは一時的なテーブル宣言でGLOBALキーワードとLOCALキーワードを受け入れますが、現在は効果がありません。 将来のバージョンのPolarDBは、より標準に準拠した意味の解釈を採用する可能性があるため、これらのキーワードの使用は推奨されません。
一時テーブルのON COMMIT句もSQL標準に似ていますが、いくつかの違いがあります。 ON COMMIT句を省略した場合、SQLはデフォルトの動作をON COMMIT DELETE ROWSと指定します。 ただし、PolarDBの既定の動作はON COMMIT PRESERVE ROWSです。 ON COMMIT DROPオプションはSQLには存在しません。
非遅延一意性制約
UNIQUEまたはPRIMARY KEY制約が延期できない場合、PolarDBは行が挿入または変更されるたびに即座に一意性をチェックします。 SQL標準では、ステートメントの最後にのみ一意性を適用する必要があると記載されています。たとえば、1つのコマンドで複数のキー値が更新される場合に違いが生じます。 標準準拠の動作を取得するには、制約をDEFERRABLEとして宣言しますが、延期はしません (つまり、INITIALLY IMMEDIATE) 。 これは、即時の一意性チェックよりも大幅に遅くなる可能性があることに注意してください。
列チェック制約
SQL標準では、CHECK列制約は適用する列のみを参照でき、CHECKテーブル制約のみが複数の列を参照できると記載されています。 PolarDBはこの制限を適用しません。列とテーブルのチェック制約を同様に扱います。
排他的制約
EXCLUDE制約タイプは、PolarDBの拡張です。
NULL "constraint"
NULL "constraint" (実際には非制約) は、他のデータベースシステムとの互換性のため (およびNOT NULL制約との対称性のため) に含まれているSQL標準のPolarDB拡張です。 任意の列のデフォルトであるため、その存在は単にノイズです。
制約の命名
SQL標準では、テーブルとドメインの制約には、テーブルまたはドメインを含むスキーマ全体で一意の名前が必要です。 PolarDBは、制約名が特定のテーブルまたはドメインにアタッチされた制約全体で一意である必要があるだけです。 ただし、インデックスベースの制約 (UNIQUE、PRIMARY KEY、およびEXCLUDE制約) にはこの追加の自由度は存在しません。これは、関連付けられたインデックスが制約と同じ名前を付けられ、インデックス名が同じスキーマ内のすべての関係で一意である必要があるためです。
現在、PolarDBはnot NULL制約の名前をまったく記録しないため、一意性の制限の対象にはなりません。 これは将来のリリースで変更される可能性があります。
継承
INHERITS句による複数の継承は、PolarDB言語拡張です。
ゼロ列テーブル
PolarDBでは、列のないテーブルを作成できます (CREATE table foo(); など) 。 これはSQL標準からの拡張であり、ゼロ列テーブルを許可しません。 ゼロ列テーブル自体はあまり有用ではありませんが、それらを許可しないと、ALTER TABLE DROP columnの奇妙な特殊なケースが作成されるため、この仕様の制限を無視する方がきれいに見えます。
複数のID列
PolarDBでは、テーブルに複数のID列を持たせることができます。 標準では、テーブルに最大で1つのID列を指定できます。 これは、主にスキーマの変更や移行の柔軟性を高めるために緩和されます。 INSERTコマンドは、ステートメント全体に適用されるオーバーライド句を1つしかサポートしていないため、動作が異なる複数のID列を使用することは十分にサポートされていません。
生成された列
オプションSTOREDは標準ではありませんが、他のSQL実装でも使用されます。 SQL標準では、生成される列のストレージは指定されていません。
LIKE句
LIKE句はSQL標準に存在しますが、PolarDBが受け入れるオプションの多くは標準に含まれておらず、標準のオプションの一部はPolarDBによって実装されていません。
WITH句
WITH句はPolarDB拡張であり、ストレージパラメーターは標準ではありません。
テーブルスペース
TABLESPACEおよびUSING INDEX TABLESPACE句は拡張機能です。
タイプされたテーブル
型付きテーブルは、SQL標準のサブセットを実装します。 標準によると、型付きテーブルには、基礎となる複合型に対応する列と、他の1つの「自己参照列」があります。 PolarDBは、自己参照列を明示的にサポートしていません。
PARTITION BY句
PARTITION BY句は拡張子です。
PARTITION OF句
PARTITION OF句は拡張子です。