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 45.18. 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.
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.