Lorsque des structures de base complexes sont créées qui impliquent beaucoup de tables avec des contraintes de clés étrangères, des vues, des déclencheurs, des fonctions, etc., un réseau de dépendances entre les objets est implicitement créé. Par exemple, une table avec une contrainte de clé étrangère dépend de la table à laquelle elle fait référence.

Pour garantir l'intégrité de la structure entière de la base, PostgreSQL™ s'assure qu'un objet dont d'autres objets dépendent ne peut pas être supprimé. Ainsi, toute tentative de suppression de la table des produits utilisée dans la Section 5.3.5, « Clés étrangères », sachant que la table des commandes en dépend, lève un message d'erreur comme celui-ci :

DROP TABLE produits;

ERROR:  cannot drop table produits because other objects depend on it
DETAIL:  constraint commandes_no_produit_fkey on table commandes depends on table produits
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

ou en français :

DROP TABLE produits;

NOTICE:  la contrainte commandes_no_produit_fkey sur la table commandes dépend
de la table produits
ERREUR:  la table produits ne peut pas être supprimée, car d'autre objets en
dépendent
HINT:  Utiliser DROP ... CASCADE pour supprimer également les objets
dépendants.

Le message d'erreur contient un indice utile : pour ne pas avoir à supprimer individuellement chaque objet dépendant, on peut lancer

DROP TABLE produits CASCADE;

et tous les objets dépendants sont ainsi effacés. Dans ce cas, la table des commandes n'est pas supprimée, mais seulement la contrainte de clé étrangère. (Pour vérifier ce que fait DROP ... CASCADE, on peut lancer DROP sans CASCADE et lire les messages DETAIL.)

Toutes les commandes DROP dans PostgreSQL™ supportent l'utilisation de CASCADE. La nature des dépendances est évidemment fonction de la nature des objets. On peut aussi écrire RESTRICT au lieu de CASCADE pour obtenir le comportement par défaut, à savoir interdire les suppressions d'objets dont dépendent d'autres objets.

Pour les fonctions définies par un utilisateur, PostgreSQL™ trace les dépendances associées avec les propriétés visibles de l'extérieur de la fonction, comme le type de données des arguments et du résultat. Il ne trace pas les dépendances qui seraient seulement connues en examinant le corps de la fonction. Par exemple, voyons cette situation :

CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
                             'green', 'blue', 'purple');

CREATE TABLE my_colors (color rainbow, note text);

CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
  'SELECT note FROM my_colors WHERE color = $1'
  LANGUAGE SQL;

(Voir Section 35.4, « Fonctions en langage de requêtes (SQL) » pour une explication sur les fonctions en langage SQL.) PostgreSQL™ saura que la fonction get_color_note dépend du type rainbow. De ce fait, supprimer le type forcera la suppression de la fonction car, dans le cas contraire, le type de l'argument ne serait plus défini. Cependant, PostgreSQL™ ne saura pas que la fonction get_color_note dépend de la table the my_colors, et donc ne supprimera pas la fonction si la table est supprimées. Bien qu'il y ait des inconvénients à cette approche, il y a aussi des avantages. La fonction est toujours valide dans certains cas si la table est manquante, bien que l'exécuter causera une erreur. Créer une nouvelle table du même nom permettra à la fonction de fonctionner de nouveau.