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.
  </para>

  <para>
   To ensure the integrity of the entire database structure,
   <productname>PostgreSQL</productname> makes sure that you cannot
   drop objects that other objects still depend on.  For example,
   attempting to drop the products table we considered in <xref
   linkend="ddl-constraints-fk"/>, with the orders table depending on
   it, would result in an error message like this:
<screen>
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.
</screen>
   The error message contains a useful hint: if you do not want to
   bother deleting all the dependent objects individually, you can run:
<screen>
DROP TABLE products CASCADE;
</screen>
   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 <command>DROP ... CASCADE</command> will do,
   run <command>DROP</command> without <literal>CASCADE</literal> and read the
   <literal>DETAIL</literal> output.)
  </para>

  <para>
   Almost all <command>DROP</command> commands in <productname>PostgreSQL</productname> support
   specifying <literal>CASCADE</literal>.  Of course, the nature of
   the possible dependencies varies with the type of the object.  You
   can also write <literal>RESTRICT</literal> instead of
   <literal>CASCADE</literal> to get the default behavior, which is to
   prevent dropping objects that any other objects depend on.
  </para>

  <note>
   <para>
    According to the SQL standard, specifying either
    <literal>RESTRICT</literal> or <literal>CASCADE</literal> is
    required in a <command>DROP</command> command.  No database system actually
    enforces that rule, but whether the default behavior
    is <literal>RESTRICT</literal> or <literal>CASCADE</literal> varies
    across systems.
   </para>
  </note>

  <para>
   If a <command>DROP</command> command lists multiple
   objects, <literal>CASCADE</literal> is only required when there