pg_depend
#
pg_depend
カタログは、データベースオブジェクト間の依存関係を記録します。
この情報によってDROP
コマンドが、他のどのオブジェクトをDROP CASCADE
で削除する必要があるか、また、DROP RESTRICT
で削除を防止するかの場合を判断します。
pg_shdepend
も参照してください。
これはデータベースクラスタ間で共有されるオブジェクトの依存関係に対する似たような機能を持っています。
表53.18 pg_depend
の列
列 型 説明 |
---|
依存するオブジェクトが存在するシステムカタログのOID |
依存する特定のオブジェクトのOID |
テーブル列の場合、これは列番号です( |
参照されるオブジェクトが存在するシステムカタログのOID |
特定の参照されるオブジェクトのOID |
テーブル列の場合、これは列番号です( |
この依存関係の特定のセマンティクスを定義するコード(後述) |
すべての場合において、pg_depend
エントリは依存するオブジェクトも削除しない限り、参照されるオブジェクトを削除できないことを示します。
もっとも、deptype
によって指定される以下のようないくつかのオプションもあります。
DEPENDENCY_NORMAL
(n
)
個別に作成されたオブジェクト間の通常の関係です。
依存するオブジェクトは参照されるオブジェクトに影響を与えずに削除できます。
参照されるオブジェクトはCASCADE
を指定することによってのみ削除できます。
この場合は依存するオブジェクトも削除されます。
例:テーブルの列はそのデータ型に対して通常の依存関係を持ちます。
DEPENDENCY_AUTO
(a
)
依存するオブジェクトは参照されるオブジェクトから独立して削除できます。
そして、参照されるオブジェクトが削除される時は(RESTRICT
もしくはCASCADE
モードに関わりなく)依存するオブジェクトも自動的に削除されなければなりません。
例:テーブル上の名前付き制約はテーブル上に自動設定されているため、テーブルが削除されるとなくなります。
DEPENDENCY_INTERNAL
(i
)
依存するオブジェクトは参照されるオブジェクトの作成時に作成されたもので、実際には内部実装の一部に過ぎません。
依存するオブジェクトに対してDROP
コマンドを直接的に実行できません
(その代わりに、参照されるオブジェクトに対してDROP
を実行するように指示されます)。
参照されるオブジェクトにDROP
を実行すると、CASCADE
が指定されているかどうかに関わらず、依存するオブジェクトも削除されます。
削除されるオブジェクトへの依存関係で依存しているオブジェクトを削除しなければらない場合、その削除は参照されるオブジェクトの削除に変換されます。
ですから依存しているオブジェクトのNORMAL
とAUTO
依存関係は、参照されるオブジェクトの依存関係に非常に似通った振る舞いをします。
例:ビューのON SELECT
ルールがビューに依存して内部的に作られ、ビューが存在する限り削除されることを防ぎます。
ルールの依存関係(たとえばそれが参照するテーブル)はビューの依存関係であるかのように振る舞います。
DEPENDENCY_PARTITION_PRI
(P
)DEPENDENCY_PARTITION_SEC
(S
)
依存するオブジェクトは参照されるオブジェクトの生成の一環で作成され、実際にはこれは内部的な実装の一部に過ぎません。
しかし、INTERNAL
とは違って複数の参照されるオブジェクトが存在します。
参照されているオブジェクトの少なくとも1つが削除されない限り、依存するオブジェクトは削除されてはいけません。
もし参照されているオブジェクトの一つが削除されたら、CASCADE
が指定されているかどうかに関わらず、依存しているオブジェクトは削除されるべきです。
また、INTERNAL
とは違って、依存オブジェクトが依存しているオブジェクトを削除してもパーティション参照オブジェクトを自動的に削除することにはなりません。
ですからその削除処理によって他の経路でこれらのオブジェクトの少なくとも1つに連鎖波及しない限り、削除は拒否されます。
(たいていの場合、依存するオブジェクトはすべての非パーティション依存関係を、少なくとも1つのパーティション参照オブジェクトと共有するので、この制限によって連鎖削除をブロックすることにはなりません。)
エラーメッセージで優先的に主パーティションが使われることを除くと、主および二次パーティション依存関係は同じように振る舞います。
よって、パーティション依存オブジェクトは一つの主パーティション依存関係と1つ以上の二次パーティション依存関係を持つはずです。
パーティション依存関係は、オブジェクトが通常持っている依存関係に加えて作成されるのであり、それを置き換えるものではないことに注意してください。
これによってATTACH/DETACH PARTITION
操作が簡単になります。
パーティション依存関係は追加されるか削除されるかのどちらかになります。
例:子パーティションインデックスは、それが作成されているパーティションテーブルと親パーティションインデックスの両方にパーティション依存します。
ですから、このどちらかが削除されると削除されますが、それ以外の場合には削除されません。
親インデックスへの依存関係は主なので、ユーザが子パーティションインデックスを削除しようとすると、エラーメッセージは(テーブルではなく)親インデックスを削除するように示唆します。
DEPENDENCY_EXTENSION
(e
)
依存するオブジェクトは参照されるオブジェクトの拡張のメンバです(pg_extension
参照)。
依存するオブジェクトは参照されるオブジェクトに対するDROP EXTENSION
経由でのみ削除できます。
機能的にはこの種類の依存関係はINTERNAL
依存関係と同様に動作しますが、明確さとpg_dumpを単純化するために別々に保持されます。
DEPENDENCY_AUTO_EXTENSION
(x
)
依存するオブジェクトは参照されるオブジェクトの拡張のメンバではありません(そしてそれゆえpg_dumpによって無視されません)が、拡張なしに機能することが出来ず、拡張自体が削除される時に自動的に削除されるでしょう。
依存するオブジェクトは、同様にそれ自身で削除されるかもしれません。
機能的にはこの種類の依存関係はAUTO
依存関係と同様に動作しますが、明確さとpg_dumpを単純化するために別々に保持されます。
将来的に、他の依存関係のオプションが必要になる可能性があります。
2つのオブジェクトが複数のpg_depend
エントリでリンクされていることは十分ありえます。
たとえば子パーティションインデックスは、パーティションテーブルに対してパーティション型依存関係を持ち、更にインデックスが貼ってあるテーブルの列に自動依存関係を持ちます。
この種の状況は、複数の依存関係セマンティクスの和で表現されます。
自動削除の条件をこの依存関係の一つが満たすならば依存するオブジェクトはCASCADE
なしに削除できます。
逆に、どのオブジェクトが一緒に削除されなければならないかに関するすべての依存関係の制限は満足されなければなりません。
initdb中に作成されたほとんどのオブジェクトは「固定(pinned)」とみなされます。
これは、システム自体がオブジェクトに依存していることを意味します。
したがって、オブジェクトを削除することは決してできません。
また、固定されたオブジェクトが削除されないことを知っているため、依存メカニズムはオブジェクトへの依存関係を示すpg_depend
エントリをわざわざ作成する必要がありません。
ですから、例えば、numeric
型のテーブル列は理論上numeric
データ型にNORMAL
依存しますが、そのようなエントリは実際にはpg_depend
にはありません。