Dependency Tracking

Definition
When you create complex database structures involving many tables with foreign key
constraints,
views, triggers, functions, etc. you implicitly create a net of dependencies
between the objects. For
instance, a table with a foreign key constraint depends on the table it references.
To ensure the integrity of the entire database structure, PostgreSQL makes sure
that you cannot drop
objects that other objects still depend on. For example, attempting to drop the
products table we con-
sidered in Section 5.4.5, with the orders table depending on it, would result in an
error message like
this:
DROP TABLE products;
ERROR: cannot drop table products because other objects depend on
it
DETAIL: constraint orders_product_no_fkey on table orders depends
on table products
HINT: Use DROP ... CASCADE to drop the dependent objects too.
The error message contains a useful hint: if you do not want to bother deleting all
the dependent objects
individually, you can run:
DROP TABLE products CASCADE;
and all the dependent objects will be removed, as will any objects that depend on
them, recursively.
In this case, it doesn't remove the orders table, it only removes the foreign key
constraint. It stops
there because nothing depends on the foreign key constraint. (If you want to check
what DROP ...
CASCADE will do, run DROP without CASCADE and read the DETAIL output.)
Almost all DROP commands in PostgreSQL support specifying CASCADE. Of course, the
nature of
the possible dependencies varies with the type of the object. You can also write
RESTRICT instead
of CASCADE to get the default behavior, which is to prevent dropping objects that
any other objects
depend on.