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.19. Colonnes de pg_depend
| Nom | Type | Références | Description |
|---|---|---|---|
| classid | oid | pg_class.oid | OID du catalogue système dans lequel l'objet dépendant se trouve. |
| objid | oid | 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 | pg_class.oid | OID du catalogue système dans lequel l'objet référencé se trouve. |
| refobjid | oid | 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 :
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.
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.
L'objet dépendant est créé conjointement à l'objet référencé et fait partie intégrante de son implantation interne. Un DROP 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é est propagée à l'objet dépendant que CASCADE soit précisé ou non. Exemple : un trigger créé pour vérifier une contrainte de clé étrangère est rendu dépendant de l'entrée de la contrainte dans pg_constraint.
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 interne mais il est séparé pour des raisons de clarté et pour simplifier pg_dump.
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 ne peut pas fonctionner sans et devrait être supprimé quand l'extension l'est. L'objet dépendant pourrait aussi être supprimé par lui-même.
Il n'y a pas d'objet dépendant ; ce type d'entrée signale que le système lui-même dépend de l'objet référencé, et donc que l'objet ne doit jamais être supprimé. Les entrées de ce type sont créées uniquement par initdb. Les colonnes de l'objet dépendant contiennent des zéros.
D'autres types de dépendance peuvent apparaître dans le futur.
pg_default_acl
