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 |
---|
OID du catalogue système dans lequel l'objet dépendant se trouve |
OID de l'objet dépendant |
Pour une colonne de table, ce champ indique le numéro de colonne (les
champs |
OID du catalogue système dans lequel l'objet référencé se trouve. |
OID de l'objet référencé |
Pour une colonne de table, ce champ indique le numéro de colonne (les
champs |
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
.