★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

53.18. pg_depend #

pg_dependカタログは、データベースオブジェクト間の依存関係を記録します。 この情報によってDROPコマンドが、他のどのオブジェクトをDROP CASCADEで削除する必要があるか、また、DROP RESTRICTで削除を防止するかの場合を判断します。

pg_shdependも参照してください。 これはデータベースクラスタ間で共有されるオブジェクトの依存関係に対する似たような機能を持っています。

表53.18 pg_dependの列

列 型

説明

classid oid (参照先 pg_class.oid

依存するオブジェクトが存在するシステムカタログのOID

objid oid (いずれかのOID列)

依存する特定のオブジェクトのOID

objsubid int4

テーブル列の場合、これは列番号です(objidclassidはテーブル自身を参照します)。 他のすべての種類のオブジェクトでは、この列はゼロです。

refclassid oid (参照先 pg_class.oid

参照されるオブジェクトが存在するシステムカタログのOID

refobjid oid (いずれかのOID列)

特定の参照されるオブジェクトのOID

refobjsubid int4

テーブル列の場合、これは列番号です(refobjidrefclassidはテーブル自身を参照します)。 他のすべての種類のオブジェクトでは、この列はゼロです。

deptype char

この依存関係の特定のセマンティクスを定義するコード(後述)


すべての場合において、pg_dependエントリは依存するオブジェクトも削除しない限り、参照されるオブジェクトを削除できないことを示します。 もっとも、deptypeによって指定される以下のようないくつかのオプションもあります。

DEPENDENCY_NORMAL (n)

個別に作成されたオブジェクト間の通常の関係です。 依存するオブジェクトは参照されるオブジェクトに影響を与えずに削除できます。 参照されるオブジェクトはCASCADEを指定することによってのみ削除できます。 この場合は依存するオブジェクトも削除されます。 例:テーブルの列はそのデータ型に対して通常の依存関係を持ちます。

DEPENDENCY_AUTO (a)

依存するオブジェクトは参照されるオブジェクトから独立して削除できます。 そして、参照されるオブジェクトが削除される時は(RESTRICTもしくはCASCADEモードに関わりなく)依存するオブジェクトも自動的に削除されなければなりません。 例:テーブル上の名前付き制約はテーブル上に自動設定されているため、テーブルが削除されるとなくなります。

DEPENDENCY_INTERNAL (i)

依存するオブジェクトは参照されるオブジェクトの作成時に作成されたもので、実際には内部実装の一部に過ぎません。 依存するオブジェクトに対してDROPコマンドを直接的に実行できません (その代わりに、参照されるオブジェクトに対してDROPを実行するように指示されます)。 参照されるオブジェクトにDROPを実行すると、CASCADEが指定されているかどうかに関わらず、依存するオブジェクトも削除されます。 削除されるオブジェクトへの依存関係で依存しているオブジェクトを削除しなければらない場合、その削除は参照されるオブジェクトの削除に変換されます。 ですから依存しているオブジェクトのNORMALAUTO依存関係は、参照されるオブジェクトの依存関係に非常に似通った振る舞いをします。 例:ビューの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にはありません。