この構文を使用すると、CREATE TABLEと同じ構文を使って新しい列をテーブルに追加できます。 IF NOT EXISTSが指定され、その名前の列が既に存在している場合は、エラーが発生しません。

この構文を使用すると、テーブルから列を削除できます。 削除する列を含んでいるインデックスおよびテーブル制約も自動的に削除されます。 削除する列を参照する多変量統計がある場合、列の削除の結果、その統計が1つの列のデータしか含まないようになるなら、それも削除されます。 また、削除する列にテーブル以外が依存（例えば、外部キー制約、ビューなど）している場合、CASCADEを付ける必要があります。 IF EXISTSが指定されている場合、もしその列がなかったとしてもエラーにはなりません。 この場合は代わりに注意が出力されます。

この構文を使用すると、テーブルの列の型を変更できます。 その列を含むインデックスと簡単なテーブル制約は、元々与えられた式を再解析し、新しい型を使用するように自動的に変換されます。 COLLATE句を使うと、新しい列の照合順を指定できます。 省略時の照合順は新しい列の型のデフォルトになります。 USING句を使うと、古い列値をどのように新しい値に計算するかを指定できます。 省略された場合、デフォルトの変換は、古いデータ型から新しいデータ型への代入キャストと同じになります。 古いデータ型から新しいデータ型への暗黙キャストあるいは代入キャストがない場合、USING句を指定しなければなりません。

これらの構文を使用すると、列のデフォルト値を設定または削除できます。 デフォルト値は、変更後に行われるINSERTまたはUPDATEコマンドにのみ適用されます。 テーブル内の既存の行は変更されません。

これらの構文は、列の値としてNULL値を使用できるかどうか設定します。 SET NOT NULLは、その列にNULL値が1つもない場合にのみ設定可能です。

このテーブルがパーティションの場合、親テーブルでNOT NULLの印がつけられている列についてDROP NOT NULLを実行することはできません。 すべてのパーティションからNOT NULL制約を削除するには、親テーブルでDROP NOT NULLを実行してください。 親テーブルにNOT NULL制約がない場合でも、望むなら各パーティションにそのような制約を追加することができます。 つまり、親テーブルがNULLを許していても子テーブルでNULLを禁止することができますが、その逆はできません。

この構文では、列がIDENTITY列であるかどうか、または既存のIDENTITY列の生成属性を変更することができます。 詳細はCREATE TABLEを参照してください。

DROP IDENTITY IF EXISTSが指定され、その列がIDENTITY列でない場合は、エラーを発生させません。 この場合、注意メッセージが発行されます。

この構文では、既存のIDENTITY列に紐付けられているシーケンスを変更します。 sequence_optionはINCREMENT BYなどALTER SEQUENCEがサポートするオプションです。

この構文は、以後のANALYZE操作において、列単位での統計情報収集対象を設定します。 対象として、0から10000までの範囲の値を設定可能です。 また、対象を-1に設定すると、システムのデフォルト統計情報対象（default_statistics_target）が使用されます。 PostgreSQLの問い合わせプランナによる統計情報の使用に関する詳細は、14.2を参照してください。

SET STATISTICSはSHARE UPDATE EXCLUSIVEロックを取得します。

この構文は属性単位のオプションの設定または設定解除を行います。 現時点では属性単位のオプションで定義されているのはn_distinctおよびn_distinct_inheritedのみです。 これらのオプションは、その後のANALYZE操作により生成される個別値数の推定値を上書きします。 n_distinctはテーブル自身の統計情報に影響を与え、n_distinct_inheritedはテーブルとそれを継承した子テーブルから集めた統計情報に影響を与えます。 正の値の場合、ANALYZEは、その列には、正確に指定された個数の非NULLの個別値が存在するものとみなします。 負の値の場合、この値は-1以上でなければなりませんが、ANALYZEは、その列内の非NULLの個別値はテーブルのサイズに線形であるとみなし、推定テーブルサイズに指定した値の絶対値を乗じた値が個別値数であるとみなします。 たとえば、-1という値は、列内のすべての値に重複がないことを意味し、-0.5という値は個々の値は平均して2回現れることを意味します。 テーブルの行数との乗算は問い合わせ計画を作成するまで行われませんので、テーブルサイズが変わり続けるような場合にこれは有用かもしれません。 0という値を指定することで、個別値数の推定を通常に戻します。 PostgreSQL問い合わせプランナにおける統計情報の使用に関しては14.2を参照してください。

属性単位のオプションの変更はSHARE UPDATE EXCLUSIVEロックを取得します。

この構文は、列の保管モードを設定します。 列をインラインで保持するか補助TOASTテーブルに保持するか、また、データを圧縮するかどうかを制御できます。 PLAINは、integerのような固定長の値に対して使用します。インラインで保持され、圧縮されません。 MAINは、インラインで保持されていて、圧縮可能なデータに使用します。 EXTERNALは圧縮されていない外部データに使用します。 EXTENDEDは圧縮された外部データに使用します。 EXTENDEDは、PLAIN以外の保管をサポートするほとんどのデータ型におけるデフォルトです。 EXTERNALを使用すると、非常に長いtextおよびbytea列に対する部分文字列操作の処理速度が向上しますが、必要な保管容量が増えるというデメリットがあります。 SET STORAGE自体はテーブルをまったく変更しないことに注意してください。 以後のテーブルの更新時に遂行する戦略を設定するだけです。 詳細は68.2を参照してください。

この構文は、CREATE TABLEと同じ構文に加え、現時点では外部キー制約と検査制約でのみ許されるNOT VALIDオプションを使って新しい制約をテーブルに追加します。 制約がNOT VALIDと印付けされた場合、テーブル内のすべての行が制約を満たすかどうかを検証するための、時間がかかるかもしれない初期検査が飛ばされます。 しかし、制約はその後の挿入や更新に対して強制されます（つまり、外部キー制約の場合、被参照テーブルに一致する行が存在しない限り失敗します。指定された検査制約に一致する新しい行が存在しない限り失敗します）。 しかしデータベースは、VALIDATE CONSTRAINTオプションを使用して検証されるまで、テーブル内のすべての行で制約が保持されているとみなしません。 パーティションテーブル上の外部キー制約は今のところNOT VALIDと宣言できません。

外部キー制約の追加には、被参照テーブルにSHARE ROW EXCLUSIVEロックが必要です。

一意性制約や主キー制約がパーティションテーブルに追加されるときには、追加的な制限が適用されます。 CREATE TABLEを参照してください。

この構文は、既存の一意性インデックスに基づき、テーブルにPRIMARY KEYまたはUNIQUE制約を新たに追加します。 インデックスのすべての列がこの制約に含まれます。

このインデックスは式列を持つことはできず、また部分インデックスであってはいけません。 またこれはデフォルトのソート順序を持つB-Treeインデックスでなければなりません。 これらの制限により、このインデックスが通常のADD PRIMARY KEYまたはADD UNIQUEコマンドにより構築されたインデックスと等価であることを確実にします。

PRIMARY KEYが指定され、インデックスの列がNOT NULLと印付けされていない場合、このコマンドはこうした列のそれぞれに対してALTER COLUMN SET NOT NULLの実施を試みます。 これは列にNULLが含まれないことを検証するために完全なテーブルスキャンを必要とします。 この他の場合においては、これが高速な操作です。

制約名が提供された場合、インデックスの名前は制約名に合うように変更されます。 提供されない場合は制約にはインデックスと同じ名前が付けられます。

このコマンドの実行後、インデックスは、制約により「所有」され、それはインデックスが通常のADD PRIMARY KEYまたはADD UNIQUEにより構築された場合と同様です。 特にこの制約を削除するとインデックスも消えてしまいます。

この形式は今のところパーティションテーブルではサポートされません。

この構文は以前に作成された制約の属性を変更します。 現在は外部キー制約のみを変更できます。

この構文は、以前にNOT VALIDとして作成された外部キー制約または検査制約を、これらの制約を満たさない行が存在しないことを確認するためにテーブルをスキャンして、検証します。 制約がすでに有効であると記録されている場合は何も起こりません。

検証は大きなテーブルに対して長いプロセスになることがあります。 制約の初期生成から検証を分離する利点は、より忙しくない時間まで検証を遅延させることができることや、新しいエラーを防ぎつつ、既存のエラーを修正する時間を用意するために使用することができることです。 また、検証それ自体は、その実行中に、テーブルに対する通常の書き込みコマンドを妨げないことにも注意してください。

検証は変更されるテーブルについてSHARE UPDATE EXCLUSIVEロックしか取得しません。 制約が外部キーの時は、制約が参照するテーブルについてROW SHAREロックも取得します。

この構文はテーブル上の指定した制約を、制約の基となるインデックスと共に削除します。 IF EXISTSが指定された場合、その制約がなくてもエラーになりません。 この場合は代わりに注意が出力されます。

この構文を使用すると、テーブルに属するトリガの発行について設定することができます。 無効にされたトリガはシステム上に存在し続けますが、トリガイベントが発生したとしても実行されません。 遅延トリガの場合、有効無効状態の確認は、トリガ関数を実際に実行しようとする時ではなく、イベントの発生時に行われます。 名前でトリガを1つ指定して有効または無効にすることもできますし、テーブル上のすべてのトリガを有効または無効にすることもできます。 また、ユーザトリガのみを有効または無効にすることも可能です （このオプションは、外部キー制約、遅延可能な一意性および排他制約を実装するために使用される内部向けに生成される制約トリガを除外します。） 内部向けに生成される制約トリガを有効または無効にするにはスーパーユーザ権限が必要です。 トリガが実行されなかった場合は当然ながら制約の整合性が保証されませんので、制約トリガの無効化は注意して実行しなければなりません。

トリガ発行機構は設定変数session_replication_roleの影響も受けます。 単に有効としたトリガ（デフォルト）では、レプリケーションロールが「origin」（デフォルト）または「local」の場合に発行されます。 ENABLE REPLICAと設定されたトリガでは、セッションが「replica」モードである場合のみ発行されます。 そして、ENABLE ALWAYSと設定されたトリガでは、現在のレプリケーションロールに関係なく発行されます。

この仕組みの効果はデフォルト設定ではレプリカ上でトリガが発行しないことです。 トリガがオリジンでテーブル間でデータを伝播するのに使われている場合にレプリケーションシステムは伝播したデータもレプリケーションします。レプリカ上でトリガが再度発動すべきではありませんので、これは有用です。 しかしながら、トリガが外部的な警告を発するなどの他の意図で使われている場合、レプリカでもトリガが発行されるようにENABLE ALWAYSを設定するのが適切と言えます。

このコマンドはSHARE ROW EXCLUSIVEを取得します。

この構文を使用すると、テーブルに属する書き換えルールの実行について設定することができます。 ルールは無効にしてもシステムに残りますが、問い合わせ書き換え時に適用されません。 この意味はトリガの有効化、無効化と同じです。 この設定はON SELECTルールでは無視されます。 現在のセッションがデフォルト以外のレプリケーションモードであったとしても、ビュー操作を維持するために常に適用されます。

前述のトリガと同様に、ルール発行機構は設定変数session_replication_roleの影響を受けます。

これらの構文は、テーブルの行セキュリティポリシーの適用を制御します。 有効にされ、かつテーブルにポリシーが存在しない場合は、デフォルトの拒絶ポリシーが適用されます。 行単位セキュリティが無効になっている場合でも、テーブルのセキュリティが存在し得ることに注意してください。 この場合、ポリシーは適用されず、無視されます。 CREATE POLICYも参照してください。

これらの構文は、ユーザがテーブルの所有者である場合について、テーブルの行セキュリティポリシーの適用を制御します。 有効の場合、ユーザがテーブルの所有者であれば、行セキュリティポリシーが適用されます。 無効（デフォルト）の場合、ユーザがテーブルの所有者であれば、行セキュリティポリシーは適用されません。 CREATE POLICYも参照してください。

この構文は、以後のCLUSTER操作用のデフォルトインデックスを選択します。 テーブルの再クラスタ化は実際には行いません。

clusterオプションの変更はSHARE UPDATE EXCLUSIVEロックを取得します。

この構文は、テーブルから、一番最後に適用されたCLUSTERインデックス指定を削除します。 以後のインデックスを指定しないクラスタ操作に影響を及ぼします。

clusterオプションの変更はSHARE UPDATE EXCLUSIVEロックを取得します。

この構文はoidシステム列をテーブルに追加します（5.4を参照してください）。 テーブルがすでにOIDを持つ場合は何も行いません。

これが、ADD COLUMN oid oidと同じではないことに注意してください。 後者はシステム列ではなくoidという名前が付いただけの通常の列を追加します。

この構文は、テーブルからoidシステム列を削除します。 既にoid列が存在しなくても警告が表示されない点を除けば、DROP COLUMN oid RESTRICTとまったく同等です。

この構文を使用すると、テーブルのテーブル空間を指定したテーブル空間に変更し、テーブルに関連するデータファイルを新しいテーブル空間に移動することができます。 テーブルにインデックスがあっても移動されません。 インデックスを移動するには、別途SET TABLESPACEコマンドを実行します。 ALL IN TABLESPACE構文を使うことで、テーブル空間内の現在のデータベースのすべてのテーブルを移動することができます。 この場合、移動されるすべてのテーブルがまずロックされ、それから一つずつ移動されます。 この構文はOWNED BYもサポートしており、これを使うと、指定のロールが所有しているテーブルだけを移動します。 NOWAITを指定した場合、必要とするすべてのロックを即座に獲得できなければ、このコマンドは失敗します。 このコマンドではシステムカタログは移動されないことに注意し、必要なら代わりにALTER DATABASEを使うか、あるいはALTER TABLEで明示的に指定してください。 information_schemaのリレーションはシステムカタログとはみなされないので、移動されます。 CREATE TABLESPACEも参照してください。

この構文は、テーブルをログを取らないテーブルからログを取るテーブルに変更、あるいはその逆を行います（UNLOGGED参照）。 これは一時テーブルに対して使うことはできません。

この構文は、1つ以上のテーブルの格納パラメータを変更します。 設定可能なパラメータの詳細に関しては格納パラメータを参照してください。 このコマンドによってテーブルの内容が即座に変更されない点に注意してください。 パラメータによりますが、期待する効果を得るためにテーブルを書き換える必要がある場合があります。 このためには、VACUUM FULL、CLUSTERまたはテーブルを強制的に書き換えるALTER TABLEの構文のいずれかを使用してください。 プランナに関連するパラメータについては、次にテーブルがロックされた時に変更が有効になるため、現在実行中の問い合わせは影響を受けません。

fillfactor、TOAST、およびautovacuumのストレージパラメータおよびプランナに関連するパラメータeffective_io_concurrency、parallel_workers、seq_page_cost、random_page_cost、n_distinct、n_distinct_inheritedについてはSHARE UPDATE EXCLUSIVEロックが獲得されます。

この構文は、1つ以上の格納パラメータをデフォルト値に再設定します。 SET同様、テーブル全体を更新するためにテーブルの書き換えが必要になる場合があります。

この構文は、対象テーブルを指定した親テーブルの子テーブルとして追加します。 その後に行われる親テーブルへの問い合わせには対象テーブルの項目も含まれます。 子テーブルとして追加するためには、対象テーブルには親テーブルと同じ列がすべて含まれていなければなりません。 （この他の列を持つこともできます。） これらの列のデータ型は一致している必要があり、親テーブルでNOT NULL制約がある場合は、子テーブルでも同様にNOT NULL制約を持たなければなりません。

また、親テーブルのCHECK制約すべてについても、一致する制約が子テーブルに存在しなければなりません。 ただし、親テーブルにおいて継承不可と印付けされている（つまりALTER TABLE ... ADD CONSTRAINT ... NO INHERIT付きで作成された）制約は除きます(これらは無視されます)。 一致する子テーブルの制約はすべて継承不可であってはなりません。 現時点ではUNIQUE、PRIMARY KEY、FOREIGN KEY制約は無視されますが、将来変更されるかもしれません。

この構文は、指定した親テーブルの子テーブル群から対象のテーブルを削除します。 親テーブルへの問い合わせでは、対象としたテーブルからのデータが含まれなくなります。

この構文は、CREATE TABLE OFで形成されたかのように、テーブルと複合型とを関連付けします。 テーブルの列名とその型のリストは、複合型のものと正確に一致していなければなりません。 ただしoidシステム列の有無は異なっていても構いません。 テーブルはどのテーブルも継承していてはいけません。 これらの制限によりCREATE TABLE OFにより作成できるテーブル定義と同等になります。

この構文は型と型付けされたテーブルの関連を取り除きます。

この構文を使用すると、テーブル、シーケンス、ビュー、マテリアライズドビュー、または外部テーブルの所有者を、指定したユーザに変更できます。

この構文を使用すると、更新あるいは削除された行を特定できるよう、先行書き込みログに書き込まれる情報を変更します。 このオプションは、論理レプリケーションが使われている場合以外は何の効果もありません。 DEFAULTはシステムテーブル以外についてのデフォルトで、主キー列があれば、その古い値を記録します。 USING INDEXは指定したインデックスに含まれる列の古い値を記録しますが、このインデックスは一意であり、部分インデックスや遅延可能インデックスではなく、またNOT NULLの列のみを含まなければなりません。 FULLは行のすべての列の古い値を記録します。 NOTHINGは古い行の情報を何も記録しません(これがシステムテーブルについてのデフォルトです)。 どの場合についても、行の古いバージョンと新しいバージョンの間で、ログに記録される列のうち少なくとも1つが変わっていなければ、古い値はログに記録されません。

RENAME構文を使用すると、テーブル（もしくは、インデックス、シーケンス、ビュー、マテリアライズドビュー、外部テーブル）の名前、テーブルの個々の列名、テーブルの制約名を変更できます。 元となるインデックスを持つ制約名を変更するとき、インデックス名も同様に変更されます。 格納されているデータへの影響はありません。

この構文を使用して、テーブルを別のスキーマに移動することができます。 関連するインデックスや制約、テーブル列により所有されるシーケンスも同様に移動されます。

この構文は、既存のテーブル（それ自体がパーティションテーブルのこともあります）を対象テーブルのパーティションとして追加します。 テーブルは、FOR VALUESを使って指定の値のパーティションとして、あるいは、DEFAULTを使ってデフォルトパーティションとして追加できます。 対象テーブルの各インデックスについて、対応するインデックスが付加されるテーブルに作られます。 また、同等のインデックスが既にある場合には、そのインデックスが、ALTER INDEX ATTACH PARTITIONが実行された場合と同様に、対象テーブルのインデックスに付加されます。 既存のテーブルが外部テーブルの場合、今のところ対象テーブルにUNIQUEインデックスがあるときにはテーブルを対象テーブルのパーティションとして追加することはできない点に注意してください（CREATE FOREIGN TABLEも参照してください）。

FOR VALUESを使ったパーティションはpartition_bound_specでCREATE TABLEと同じ構文を使います。 パーティション境界の指定は、対象テーブルのパーティション戦略とパーティションキーと対応していなければなりません。 付加されるテーブルは、対象と全て同じ列を持ち、それ以上の列は持たず、列の型も一致していなければなりません。 また、対象テーブルにある全てのNOT NULLおよびCHECK制約を持たなければなりません。 今のところ、FOREIGN KEY制約は考慮されません。 親テーブルのUNIQUEおよびPRIMARY KEY制約は、既に在るのでなければ、パーティションに作られます。 もし、アタッチされるテーブルのいずれかのCHECK制約がNO INHERITと印付けされていたなら、コマンドは失敗します。 このような制約はNO INHERIT句なしに再作成しなければなりません。

新しいパーティションが通常のテーブルの場合、パーティションの制約に違反する行がテーブルに存在しないことを確認するため、テーブルの全件走査が行われます。 このコマンドを実行するより前に、望まれるパーティションの制約を満たす行だけしか許さないような有効なCHECK制約をテーブルに追加すれば、この全件走査を避けることができます。 パーティションの制約を確認するためにテーブルをスキャンしなくても良いことは、そのような制約を使って決定されます。 しかし、パーティションキーに式が一つでもあり、それがNULL値を受け付けないときは、この仕組みは機能しません。 NULL値を受け付けないリストパーティションに追加するときも、それが式でないなら、パーティションキーの列にNOT NULL制約を追加してください。

新しいパーティションが外部テーブルの場合、外部テーブルのすべての行がパーティションの制約に従うかどうかの確認は何も行われません。 （外部テーブルの制約についてはCREATE FOREIGN TABLEの議論を参照してください。）

テーブルがデフォルトパーティションを持っている場合、新たなパーティションの定義はデフォルトパーティションに対するパーティション制約を変更します。 デフォルトパーティションは新パーティションに移動すべきいかなる行を含むことができず、そのような行が無いことを確認するためスキャンが行われます。 このスキャンは、新パーティションのスキャンと同様に、適切なCHECK制約があれば回避できます。 やはり、新パーティションのスキャンと同様に、デフォルトパーティションが外部テーブルであるときは、このスキャンは常に省略されます。

この構文は、指定したパーティションを対象のテーブルから切り離します。 切り離されたパーティションは単独のテーブルとして存在し続けますが、切り離される前のテーブルとの紐付けはなくなります。 対象テーブルのインデックスに付加されていた全てのインデックスも切り離されます。

テーブルが存在しない場合でもエラーとしません。 この場合は注意メッセージが発行されます。

変更対象となる既存のテーブルの名前です（スキーマ修飾名も可）。 テーブル名の前にONLYが指定された場合、そのテーブルのみが変更されます。 ONLYが指定されていない場合、そのテーブルおよび（もしあれば）そのテーブルを継承する全てのテーブルが更新されます。 オプションで、テーブル名の後に*を指定することで、明示的に継承するテーブルも含まれることを示すことができます。

新規または既存の列の名前です。

既存の列の新しい名前です。

テーブルの新しい名前です。

新しい列のデータ型、もしくは既存の列に対する新しいデータ型です。

テーブルの新しいテーブル制約です。

新しい、あるいは既存の制約の名前です。

削除された列や制約に依存しているオブジェクト（例えば、削除された列を参照しているビューなど）を自動的に削除し、さらにそれらのオブジェクトに依存するすべてのオブジェクトも削除します（5.13参照）。

依存しているオブジェクトがある場合、列または制約の削除要求を拒否します。 これがデフォルトの動作です。

有効または無効にする単一のトリガの名前です。

テーブルに属するすべてのトリガを有効または無効にします。 （外部キー制約、遅延可能な一意性および排他制約を実装するために使用される、内部向けに生成される制約トリガが含まれる場合、スーパーユーザ権限が必要です。）

外部キー制約、遅延可能な一意性および排他制約を実装するために使用される、内部向けに生成されるトリガを除く、テーブルに属するトリガすべてを有効または無効にします。

既存のインデックスの名前です。

テーブルの格納パラメータの名前です。

テーブルの格納パラメータの新しい値です。 パラメータによりこれは数値となることも文字列となることもあります。

このテーブルに関連付ける、または、このテーブルから関連付けを取り除く親テーブルです。

テーブルの新しい所有者のユーザ名です。

テーブルを移動する先のテーブル空間の名前です。

テーブルを移動する先のスキーマの名前です。

新しいパーティションとして追加する、またはテーブルから切り離すテーブルの名前です。

新しいパーティションのパーティション境界の指定です。 その構文の詳細についてはCREATE TABLEを参照してください。