within each session, though its definition is still shared
    across sessions.  Since <productname>PostgreSQL</productname> does not
    support SQL modules, this distinction is not relevant in
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    For compatibility's sake, <productname>PostgreSQL</productname> will
    accept the <literal>GLOBAL</literal> and <literal>LOCAL</literal> keywords
    in a temporary table declaration, but they currently have no effect.
    Use of these keywords is discouraged, since future versions of
    <productname>PostgreSQL</productname> might adopt a more
    standard-compliant interpretation of their meaning.
   </para>

   <para>
    The <literal>ON COMMIT</literal> clause for temporary tables
    also resembles the SQL standard, but has some differences.
    If the <literal>ON COMMIT</literal> clause is omitted, SQL specifies that the
    default behavior is <literal>ON COMMIT DELETE ROWS</literal>.  However, the
    default behavior in <productname>PostgreSQL</productname> is
    <literal>ON COMMIT PRESERVE ROWS</literal>.  The <literal>ON COMMIT
    DROP</literal> option does not exist in SQL.
   </para>
  </refsect2>

  <refsect2>
   <title>Non-Deferred Uniqueness Constraints</title>

   <para>
    When a <literal>UNIQUE</literal> or <literal>PRIMARY KEY</literal> constraint is
    not deferrable, <productname>PostgreSQL</productname> checks for
    uniqueness immediately whenever a row is inserted or modified.
    The SQL standard says that uniqueness should be enforced only at
    the end of the statement; this makes a difference when, for example,
    a single command updates multiple key values.  To obtain
    standard-compliant behavior, declare the constraint as
    <literal>DEFERRABLE</literal> but not deferred (i.e., <literal>INITIALLY
    IMMEDIATE</literal>).  Be aware that this can be significantly slower than
    immediate uniqueness checking.
   </para>
  </refsect2>

  <refsect2>
   <title>Column Check Constraints</title>

   <para>
    The SQL standard says that <literal>CHECK</literal> column constraints
    can only refer to the column they apply to; only <literal>CHECK</literal>
    table constraints can refer to multiple columns.
    <productname>PostgreSQL</productname> does not enforce this
    restriction; it treats column and table check constraints alike.
   </para>
  </refsect2>

  <refsect2>
   <title><literal>EXCLUDE</literal> Constraint</title>

   <para>
    The <literal>EXCLUDE</literal> constraint type is a
    <productname>PostgreSQL</productname> extension.
   </para>
  </refsect2>

  <refsect2>
   <title>Foreign Key Constraints</title>

   <para>
    The ability to specify column lists in the foreign key actions
    <literal>SET DEFAULT</literal> and <literal>SET NULL</literal> is a
    <productname>PostgreSQL</productname> extension.
   </para>

   <para>
    It is a <productname>PostgreSQL</productname> extension that a
    foreign key constraint may reference columns of a unique index instead of
    columns of a primary key or unique constraint.
   </para>
  </refsect2>

  <refsect2>
   <title><literal>NULL</literal> <quote>Constraint</quote></title>

   <para>
    The <literal>NULL</literal> <quote>constraint</quote> (actually a
    non-constraint) is a <productname>PostgreSQL</productname>
    extension to the SQL standard that is included for compatibility with some
    other database systems (and for symmetry with the <literal>NOT
    NULL</literal> constraint).  Since it is the default for any
    column, its presence is simply noise.
   </para>
  </refsect2>

  <refsect2>
   <title>Constraint Naming</title>

   <para>
    The SQL standard says that table and domain constraints must have names
    that are unique across the schema containing the table or domain.
    <productname>PostgreSQL</productname> is laxer: it only requires
    constraint names to be unique across the constraints attached to a
    particular table or domain.