PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 17.1 » Internes » Catalogues système » pg_depend

51.18. pg_depend #

Le catalogue pg_depend enregistre les relations de dépendances entre les objets de la base de données. Cette information permet à la commande DROP de trouver les objets qui doivent être supprimés conjointement par la commande DROP CASCADE ou au contraire empêchent la suppression dans le cas de DROP RESTRICT.

Voir aussi pg_shdepend, qui remplit la même fonction pour les dépendances impliquant des objets partagés sur tout le cluster.

Tableau 51.18. Colonnes de pg_depend

Type

Description

classid oid (référence pg_class.oid)

OID du catalogue système dans lequel l'objet dépendant se trouve

objid oid (référence toute colonne OID)

OID de l'objet dépendant

objsubid int4

Pour une colonne de table, ce champ indique le numéro de colonne (les champs objid et classid font référence à la table elle-même). Pour tous les autres types d'objets, cette colonne est à 0.

refclassid oid (référence pg_class.oid)

OID du catalogue système dans lequel l'objet référencé se trouve.

refobjid oid (référence toute colonne OID)

OID de l'objet référencé

refobjsubid int4

Pour une colonne de table, ce champ indique le numéro de colonne (les champs refobjid et refclassid font référence à la table elle même). Pour tous les autres types d'objets, cette colonne est à 0.

deptype char

Code définissant la sémantique particulière de la relation de dépendance. Voir le texte.


Dans tous les cas, une entrée de pg_depend indique que l'objet de référence ne peut pas être supprimé sans supprimer aussi l'objet dépendant. Néanmoins, il y a des nuances, identifiées par deptype :

DEPENDENCY_NORMAL (n)

Une relation normale entre des objets créés séparément. L'objet dépendant peut être supprimé sans affecter l'objet référencé. Ce dernier ne peut être supprimé qu'en précisant l'option CASCADE, auquel cas l'objet dépendant est supprimé lui-aussi. Exemple : une colonne de table a une dépendance normale avec ses types de données.

DEPENDENCY_AUTO (a)

L'objet dépendant peut être supprimé séparément de l'objet référencé, mais il l'est automatiquement avec la suppression de ce dernier, quel que soit le mode RESTRICT ou CASCADE. Exemple : une contrainte nommée sur une table est auto-dépendante de la table, elle est automatiquement supprimée avec celle-ci.

DEPENDENCY_INTERNAL (i)

L'objet dépendant est créé conjointement à l'objet référencé et fait partie intégrante de son implantation interne. Un DROP direct de l'objet dépendant est interdit (l'utilisateur est averti qu'il peut effectuer un DROP de l'objet référencé à la place). La suppression de l'objet référencé résultera en une suppression automatique de l'objet dépendant que CASCADE soit précisé ou non. Si l'objet dépendant doit être supprimé à cause de la dépendance en un autre objet en cours de suppression, la suppression est convertie en une suppression de l'objet référencé, pour que les dépendances NORMAL et AUTO de l'objet dépendant se comportent comme s'ils s'agissaient de dépendances de l'objet référencé. Par exemple, la règle ON SELECT d'une vue est rendue en interne dépendante de la vue, empêchant sa suppression tant que la vue existe. Les dépendances de la règle (comme les tables auxquelles elle fait référence) agissent comme si elles dépendaient de la vue.

DEPENDENCY_PARTITION_PRI (P)
DEPENDENCY_PARTITION_SEC (S)

L'objet dépendant a été créé lors de la création de l'objet référencé, mais il s'agit vraiment d'un détail d'implémentation interne. Néanmoins, contrairement à INTERNAL, il existe plus d'un objet référencé. L'objet dépendant ne doit pas être supprimé sauf si au moins un des objets référencés est supprimé ; si c'est le cas, l'objet dépendant doit être supprimé que CASCADE soit indiqué ou pas. De plus, contrairement à INTERNAL, une suppression de certains autres objets dont l'objet dépendant dépend ne résulte pas en une suppression automatique d'objet référencé par une patition. De ce fait, si la suppression ne cascade pas vers au moins un de ces objets via un autre chemin, elle sera refusée. (Dans la plupart des cas, l'objet dépendant partage toutes ses dépendances non-partitions avec au moins un objet référencé par partition, donc cette restriction ne résulte pas dans le blocage de suppression en cascade). Les dépendances de partitions primaire et secondaire se comportent de façon identique sauf que la dépendance primaire est préféré pour une utilisation dans les messages d'erreur. De ce fait, un objet dépendant d'une partition devrait avoir une dépendance de partition primaire et une ou plusieurs dépendances de partition secondaires. Notez que les dépendances de partition sont faites en plus, et non pas à la place, de toute dépendant que l'objet aurait normalement. Ceci simplifie les opérations ATTACH/DETACH PARTITION : les dépendances partitions ont seulement besoin d'être ajoutées ou supprimées. Par exemple, une partition d'un index est rendue dépendante de la partition de la table et de l'index partitionné, pour qu'elle disparaisse si l'un des deux est supprimé, mais pas autrement. La dépendance sur l'index parent est primaire, pour que si l'utilisateur essaie de supprimer l'index partitionné, le message d'erreur suggèrera la suppression de l'index parent à la place (et non pas de la table).

DEPENDENCY_EXTENSION (e)

L'objet dépendant est un membre de l'extension qui est l'objet référencé (voir pg_extension). L'objet dépendant peut être supprimé seulement via l'instruction DROP EXTENSION sur l'objet référence. Fonctionnellement, ce type de dépendance agit de la même façon qu'une dépendance INTERNAL mais il est séparé pour des raisons de clarté et pour simplifier pg_dump.

DEPENDENCY_AUTO_EXTENSION (x)

L'objet dépendant n'est pas un membre de l'extension qui est l'objet référencé (et donc ne doit pas être ignoré par pg_dump), mais il ne peut fonctionner sans l'extension et doit être supprimé automatiquement si l'extension l'est. L'objet dépendant peut aussi être supprimé tout seul. Fonctionnellement, ce type de dépendance agit de la même façon que la dépendance AUTO, mais il est séparé pour des raisons de clareté et pour simplifier pg_dump.

D'autres types de dépendance peuvent apparaître dans le futur.

Notez qu'il est bien possible que les deux objets soient liés par plus d'un enregistrement dans pg_depend. Par exemple, un index fils partitionné pourrait avoir à la fois une dépendance de type partition sur la table partitionnée associée et une dépendance automatique de chaque colonne de la table qu'il indexe. Ce type de situation exprime l'union de plusieurs sémantiques de dépendances. Un objet dépendant peut être supprimé sans CASCADE si toutes ses dépendances satisfont la condition de suppression automatique. Dans le cas contraire, toutes les restrictions de dépendance sur les objets à supprimer ensemble doivent être satisfaites.

La plupart des objets créés lors de l'exécution d'initdb sont considérés « fixés », ce qui signifie que le système lui-même dépend de ces objets. De ce fait, il n'est pas autorisé de les supprimer. De plus, sachant que ces objets fixés ne seront pas supprimés, le mécanisme de dépendance ne s'occupe pas de créer les entrées dans pg_depend montrant les dépendances entre eux. De ce fait, par exemple, une colonne d'une table de type numeric a une dépendance de type NORMAL sur le type de données numeric, mais cette dépendance n'apparaît pas dans pg_depend.