Documentation PostgreSQL 15.15 » Internes » Catalogues système » `pg_depend`

Précédent | Niveau supérieur | Suivant
53.17. `pg_default_acl` | Sommaire | 53.19. `pg_description`

## 53.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 53.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`.