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,
EnterpriseDB makes sure that you cannot
drop objects that other objects still depend on. For example,
attempting to drop the dept table we had considered in Section 4.4.5, with the emp table depending on
it, would result in an error message such as this:
DROP TABLE dept;
NOTICE: constraint emp_ref_dept_fk on table emp depends on table dept
ERROR: cannot drop table emp because other objects depend on it
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 dept CASCADE;
and all the dependent objects will be removed.
All drop commands in EnterpriseDB support
specifying CASCADE CONSTRAINT. 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 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
whether the default behavior is RESTRICT or
CASCADE varies across systems.