Documentation PostgreSQL 8.0.25 | ||||
---|---|---|---|---|
Précédent | Arrière rapide | Chapitre 41. Catalogues système | Avance rapide | Suivant |
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 quels autres objets doivent être supprimés par la commande DROP CASCADE ou au contraire empêchent la suppression dans le cas de DROP RESTRICT.
Tableau 41-13. 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 se réfèrent à la table elle-même). Pour tous les autres types d'objets, cette colonne est à zéro. | |
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 se réfèrent à la table elle même). Pour tous les autres types d'objets, cette colonne est à zéro. | |
deptype | char | Code définissant la sémantique de cette relation de dépendance. Voir le texte. |
Dans tous les cas, une entrée dans pg_depend indique que l'objet 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é. L'objet référencé 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 de référence, et doit être automatiquement supprimé si l'objet référencé est supprimé, quel que soit le mode RESTRICT ou CASCADE. Exemple : une contrainte nommée sur une table est auto-dépendante sur la table et sera automatiquement supprimée en même temps que la table.
L'objet dépendant a été créé comme une partie de l'objet référencé et n'est réellement qu'une partie de son implémentation interne. Un DROP de l'objet dépendant sera interdit (avec un message à l'utilisateur lui proposant de faire un DROP de l'objet référencé à la place). Une suppression de l'objet référencé sera propagée à l'objet dépendant que CASCADE soit précisé ou non. Exemple : un trigger qui est créé pour vérifier une contrainte de clé étrangère, est rendu dépendant de l'entrée de la contrainte dans pg_constraint.
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 pour l'objet dépendant contiennent des zéros.
D'autres types de dépendance pourraient apparaître dans le futur.
Précédent | Sommaire | Suivant |
pg_database | Niveau supérieur | pg_description |