<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 are
   dependencies outside the specified group.  For example, when saying
   <literal>DROP TABLE tab1, tab2</literal> the existence of a foreign
   key referencing <literal>tab1</literal> from <literal>tab2</literal> would not mean
   that <literal>CASCADE</literal> is needed to succeed.
  </para>

  <para>
   For a user-defined function or procedure whose body is defined as a string
   literal, <productname>PostgreSQL</productname> tracks
   dependencies associated with the function's externally-visible properties,
   such as its argument and result types, but <emphasis>not</emphasis> dependencies
   that could only be known by examining the function body.  As an example,
   consider this situation:

<programlisting>
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;
</programlisting>

   (See <xref linkend="xfunc-sql"/> for an explanation of SQL-language
   functions.)  <productname>PostgreSQL</productname> will be aware that
   the <function>get_color_note</function> function depends on the <type>rainbow</type>
   type: dropping the type would force dropping the function, because its
   argument type would no longer be defined.  But <productname>PostgreSQL</productname>
   will not consider <function>get_color_note</function> to depend on
   the <structname>my_colors</structname> table, and so will not drop the function if
   the table is dropped.  While there are disadvantages to this approach,
   there are also benefits.  The function is still valid in some sense if the
   table is missing, though executing it would cause an error; creating a new
   table of the same name would allow the function to work again.
  </para>

  <para>
   On the other hand, for an SQL-language function or procedure whose body
   is written in SQL-standard style, the body is parsed at function
   definition time and all dependencies recognized by the parser are
   stored.  Thus, if we write the function above as

<programlisting>
CREATE FUNCTION get_color_note (rainbow) RETURNS text
BEGIN ATOMIC
  SELECT note FROM my_colors WHERE color = $1;
END;
</programlisting>

   then the function's dependency on the <structname>my_colors</structname>
   table will be known and enforced by <command>DROP</command>.
  </para>
 </sect1>

</chapter>