2.8. Dependency Tracking

When you create complex database structures involving many tables with foreign key constraints, views, triggers, functions, etc. you will 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 had considered in Section 2.3.5, with the orders table depending on it, would result in an error message such as this:

    DROP TABLE products;
    NOTICE:  constraint $1 on table orders depends on table products
    ERROR:  Cannot drop table products because other objects depend on it
            Use DROP ... CASCADE to drop the dependent objects too

The error message contains a useful hint: If you don't want to bother deleting all the dependent objects individually, you can run

    DROP TABLE products CASCADE;

and all the dependent objects will be removed. Actually, this doesn't remove the orders table, it only removes the foreign key constraint.

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 restrict drops of objects that other objects depend on.

Note: According to the SQL standard, specifying either RESTRICT or CASCADE is required. No database system actually implements it that way, but the defaults might be different.

Note: Foreign Key constraint dependencies and SERIAL dependencies from PostgreSQL versions prior to 7.3 are not maintained or created during the upgrade process. However, all other dependency types are created successfully.