</programlisting>
   </para>

   <para>
    The default <literal>ON DELETE</literal> action is <literal>ON DELETE NO
    ACTION</literal>; this does not need to be specified.  This means that the
    deletion in the referenced table is allowed to proceed.  But the
    foreign-key constraint is still required to be satisfied, so this
    operation will usually result in an error.  But checking of foreign-key
    constraints can also be deferred to later in the transaction (not covered
    in this chapter).  In that case, the <literal>NO ACTION</literal> setting
    would allow other commands to <quote>fix</quote> the situation before the
    constraint is checked, for example by inserting another suitable row into
    the referenced table or by deleting the now-dangling rows from the
    referencing table.
   </para>

   <para>
    <literal>RESTRICT</literal> is a stricter setting than <literal>NO
    ACTION</literal>.  It prevents deletion of a referenced row.
    <literal>RESTRICT</literal> does not allow the check to be deferred until
    later in the transaction.
   </para>

   <para>
    <literal>CASCADE</literal> specifies that when a referenced row is deleted,
    row(s) referencing it should be automatically deleted as well.
   </para>

   <para>
    There are two other options:
    <literal>SET NULL</literal> and <literal>SET DEFAULT</literal>.
    These cause the referencing column(s) in the referencing row(s)
    to be set to nulls or their default
    values, respectively, when the referenced row is deleted.
    Note that these do not excuse you from observing any constraints.
    For example, if an action specifies <literal>SET DEFAULT</literal>
    but the default value would not satisfy the foreign key constraint, the
    operation will fail.
   </para>

   <para>
    The appropriate choice of <literal>ON DELETE</literal> action depends on
    what kinds of objects the related tables represent.  When the referencing
    table represents something that is a component of what is represented by
    the referenced table and cannot exist independently, then
    <literal>CASCADE</literal> could be appropriate.  If the two tables
    represent independent objects, then <literal>RESTRICT</literal> or
    <literal>NO ACTION</literal> is more appropriate; an application that
    actually wants to delete both objects would then have to be explicit about
    this and run two delete commands.  In the above example, order items are
    part of an order, and it is convenient if they are deleted automatically
    if an order is deleted.  But products and orders are different things, and
    so making a deletion of a product automatically cause the deletion of some
    order items could be considered problematic.  The actions <literal>SET
    NULL</literal> or <literal>SET DEFAULT</literal> can be appropriate if a
    foreign-key relationship represents optional information.  For example, if
    the products table contained a reference to a product manager, and the
    product manager entry gets deleted, then setting the product's product
    manager to null or a default might be useful.
   </para>

   <para>
    The actions <literal>SET NULL</literal> and <literal>SET DEFAULT</literal>
    can take a column list to specify which columns to set.  Normally, all
    columns of the foreign-key constraint are set; setting only a subset is
    useful in some special cases.  Consider the following example:
<programlisting>
CREATE TABLE tenants (
    tenant_id integer PRIMARY KEY
);

CREATE TABLE users (
    tenant_id integer REFERENCES tenants ON DELETE CASCADE,
    user_id integer NOT NULL,
    PRIMARY KEY (tenant_id, user_id)
);

CREATE TABLE posts (
    tenant_id integer REFERENCES tenants ON DELETE CASCADE,
    post_id integer NOT NULL,
    author_id integer,
    PRIMARY KEY (tenant_id, post_id),
    FOREIGN KEY (tenant_id, author_id) REFERENCES users ON DELETE SET NULL <emphasis>(author_id)</emphasis>
);
</programlisting>
    Without