PostgreSQLは、データベース設計者にとって便利なテーブルの継承を実装しています。 （SQL:1999以降は型の継承を定義していますが、ここで述べられている継承とは多くの点で異なっています。）

まず例から始めましょう。 市（cities）のデータモデルを作成しようとしていると仮定してください。 それぞれの州にはたくさんの市がありますが、州都（capitals）は1つのみです。 どの州についても州都を素早く検索したいとします。 これは、2つのテーブルを作成することにより実現できます。 1つは州都のテーブルで、もう1つは州都ではない市のテーブルです。 しかし、州都であるか否かに関わらず、市に対するデータを問い合わせたいときには何が起こるでしょうか？ 継承はこの問題を解決できます。 citiesから継承されるcapitalsテーブルを定義するのです。

CREATE TABLE cities (
    name            text,
    population      float,
    elevation       int     -- in feet
);

CREATE TABLE capitals (
    state           char(2)
) INHERITS (cities);

この場合、capitalsテーブルは、その親テーブルであるcitiesテーブルの列をすべて継承します。 州都は1つの追加の列stateを持ち、州を表現します。

PostgreSQLでは、1つのテーブルは、0以上のテーブルから継承することが可能です。 また、問い合わせはテーブルのすべての行、またはテーブルのすべての行と継承されたテーブルのすべての行のいずれかを参照できます。 後者がデフォルトの動作になります。 例えば次の問い合わせは、500フィートより高い標高に位置しているすべての市の名前を、州都を含めて検索します。

SELECT name, elevation
    FROM cities
    WHERE elevation > 500;

PostgreSQLチュートリアルからのサンプルデータ（2.1を参照してください）に対して、この問い合わせは、以下の結果を出力します。

   name    | elevation
-----------+-----------
 Las Vegas |      2174
 Mariposa  |      1953
 Madison   |       845

一方、次の問い合わせは、州都ではなく500フィートより高い高度に位置しているすべての市を検索します。

SELECT name, elevation
    FROM ONLY cities
    WHERE elevation > 500;

   name    | elevation
-----------+-----------
 Las Vegas |      2174
 Mariposa  |      1953

ここでONLYキーワードは、問い合わせがcitiesテーブルのみを対象にしcities以下の継承の階層にあるテーブルは対象としないことを意味します。 これまで議論したコマンドの多く—SELECT、UPDATEそしてDELETE —がONLYキーワードをサポートしています。

また、明示的に子孫テーブルが含まれていることを示すために、テーブル名の後ろに*を書くこともできます:

SELECT name, elevation
    FROM cities*
    WHERE elevation > 500;

*の指定は、その動作が常にデフォルトであるため、必要ありません。 しかし、この構文はデフォルトが変更可能であった古いリリースとの互換性のためにまだサポートされています。

ある特定の行がどのテーブルからきたものか知りたいという場合もあるでしょう。 それぞれのテーブルにはtableoidという、元になったテーブルを示すシステム列があります。

SELECT c.tableoid, c.name, c.elevation
FROM cities c
WHERE c.elevation > 500;

出力は以下の通りです。

 tableoid |   name    | elevation
----------+-----------+-----------
   139793 | Las Vegas |      2174
   139793 | Mariposa  |      1953
   139798 | Madison   |       845

（この例をそのまま実行しても、おそらく異なる数値OIDが得られるでしょう。） pg_classと結合することで、テーブルの実際の名前が分かります。

SELECT p.relname, c.name, c.elevation
FROM cities c, pg_class p
WHERE c.elevation > 500 AND c.tableoid = p.oid;

出力は以下の通りです。

 relname  |   name    | elevation
----------+-----------+-----------
 cities   | Las Vegas |      2174
 cities   | Mariposa  |      1953
 capitals | Madison   |       845

同じ効果を得る別の方法は、別名型regclassを使うことで、これによりテーブルのOIDを記号的に表示します。

SELECT c.tableoid::regclass, c.name, c.elevation
FROM cities c
WHERE c.elevation > 500;

継承はINSERTまたはCOPYによるデータを、継承の階層にある他のテーブルに自動的に伝播しません。 この例では、次のINSERT文は失敗します。

INSERT INTO cities (name, population, elevation, state)
VALUES ('Albany', NULL, NULL, 'NY');

データが、どうにかしてcapitalsテーブルに入ることを期待するかもしれませんが、そのようにはなりません。 INSERTは、いつも指定されたテーブルそれ自体に対してデータを挿入します。 ルール（詳細は第41章を参照してください）を使用して挿入を中継できる場合もあります。 しかし、ルールを使用しても上記のような場合は解決できません。 なぜなら、citiesテーブルにstate列が含まれていないため、ルールが適用される前にコマンドが拒否されてしまうからです。

親テーブル上の検査制約と非NULL制約は、NO INHERIT句によって明示的に指定され無い限り、その子テーブルに自動的に継承されます。 他の種類の制約（一意性制約、主キー、外部キー制約）は継承されません。

テーブルは1つ以上の親テーブルから継承可能です。 この場合、テーブルは親テーブルで定義された列の和になります。 子テーブルで宣言された列は、これらの列に追加されることになります。 もし親テーブルに同じ名前の列がある場合、もしくは、親テーブルと子テーブルに同じ名前の列がある場合は、列が「統合」されて子テーブルではただ1つの列となります。 統合されるには列は同じデータ型を持っている必要があります。 異なるデータ型の場合にはエラーとなります。 継承可能な検査制約と非NULL制約は、同じようなやり方で統合されます。 つまり、例えば、列定義のいずれかが非NULL制約の印が付いているならば、統合された列に非NULLという印が付きます。 検査制約は、同じ名前を持っている場合に統合され、それらの条件が異なる場合は統合に失敗します。

テーブル継承は、通常、CREATE TABLE文のINHERITS句を使用して、子テーブルを作成する時に確立します。 他にも、互換性を持つ方法で定義済みのテーブルに新しく親子関係を付けることも可能です。 これにはALTER TABLEのINHERIT形式を使用します。 このためには、新しい子テーブルは親テーブルと同じ名前の列を持ち、その列の型は同じデータ型でなければなりません。 また、親テーブルと同じ名前、同じ式の検査制約を持っていなければなりません。 ALTER TABLEのNO INHERIT形式を使用して、同様に継承関係を子テーブルから取り除くことも可能です。 このような継承関係の動的追加、動的削除は、継承関係をテーブル分割（5.11を参照）に使用している場合に有用です。

後で子テーブルとする予定の、互換性を持つテーブルを簡単に作成する方法の1つは、CREATE TABLEでLIKE句を使用することです。 これは、元としたテーブルと同じ列を持つテーブルを新しく作成します。 新しい子テーブルが必ず親テーブルと一致する制約を持ち、互換性があるものとみなされるように、元となるテーブルでCHECK制約が存在する場合は、LIKEにINCLUDING CONSTRAINTSオプションを指定すべきです。

子テーブルが存在する場合親テーブルを削除することはできません。 また、子テーブルでは、親テーブルから継承した列、または検査制約を削除することも変更することもできません。 テーブルとそのすべての子テーブルを削除したければ、CASCADEオプションを付けて親テーブルを削除することが簡単な方法です（5.14を参照）。

ALTER TABLEは、列データ定義と検査制約の変更を継承の階層にあるテーブルに伝えます。 ここでも、他のテーブルに依存する列の削除はCASCADEオプションを使用したときのみ可能となります。 ALTER TABLEは、重複列の統合と拒否について、CREATE TABLE時に適用される規則に従います。

継承された問い合わせは、親テーブルのみアクセス権限を検査します。 つまり、例えば、UPDATE権限をcitiesテーブルに付与することは、citiesテーブルを通じてアクセスする場合に、capitalsテーブルにも行の更新権限を付与することを意味します。 これによりデータが親テーブルに（も）あるように見えることが保たれます。 しかし、capitalsテーブルは、追加権限なしに直接更新することはできません。 同様に、親テーブルの行セキュリティポリシー（5.8を参照してください）が、継承された問い合わせの時に子テーブルの行に適用されます。 子テーブルのポリシー（あれば）は、問い合わせにて明示的に指定されたテーブルである時にのみ適用されます。 そしてこの場合、親テーブルに紐付けられたあらゆるポリシーは無視されます。

外部テーブル（5.12参照）も通常のテーブルと同様、親テーブルあるいは子テーブルとして継承の階層の一部となりえます。 外部テーブルが継承の階層の一部となっている場合、外部テーブルがサポートしない操作は、その継承全体でもサポートされません。