identifying a set of columns as the primary key also provides metadata
      about the design of the schema, since a primary key implies that other
      tables can rely on this set of columns as a unique identifier for rows.
     </para>

     <para>
      When placed on a partitioned table, <literal>PRIMARY KEY</literal>
      constraints share the restrictions previously described
      for <literal>UNIQUE</literal> constraints.
     </para>

     <para>
      Adding a <literal>PRIMARY KEY</literal> constraint will automatically
      create a unique btree index on the column or group of columns used in
      the constraint, or GiST if <literal>WITHOUT OVERLAPS</literal> was
      specified.
     </para>

     <para>
      The optional <literal>INCLUDE</literal> clause adds to that index
      one or more columns that are simply <quote>payload</quote>: uniqueness
      is not enforced on them, and the index cannot be searched on the basis
      of those columns.  However they can be retrieved by an index-only scan.
      Note that although the constraint is not enforced on included columns,
      it still depends on them.  Consequently, some operations on such columns
      (e.g., <literal>DROP COLUMN</literal>) can cause cascaded constraint and
      index deletion.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-exclude">
    <term><literal>EXCLUDE [ USING <replaceable class="parameter">index_method</replaceable> ] ( <replaceable class="parameter">exclude_element</replaceable> WITH <replaceable class="parameter">operator</replaceable> [, ... ] ) <replaceable class="parameter">index_parameters</replaceable> [ WHERE ( <replaceable class="parameter">predicate</replaceable> ) ]</literal></term>
    <listitem>
     <para>
      The <literal>EXCLUDE</literal> clause defines an exclusion
      constraint, which guarantees that if
      any two rows are compared on the specified column(s) or
      expression(s) using the specified operator(s), not all of these
      comparisons will return <literal>TRUE</literal>.  If all of the
      specified operators test for equality, this is equivalent to a
      <literal>UNIQUE</literal> constraint, although an ordinary unique constraint
      will be faster.  However, exclusion constraints can specify
      constraints that are more general than simple equality.
      For example, you can specify a constraint that
      no two rows in the table contain overlapping circles
      (see <xref linkend="datatype-geometric"/>) by using the
      <literal>&amp;&amp;</literal> operator.
      The operator(s) are required to be commutative.
     </para>

     <para>
      Exclusion constraints are implemented using
      an index that has the same name as the constraint, so each specified
      operator must be associated with an appropriate operator class
      (see <xref linkend="indexes-opclass"/>) for the index access
      method <replaceable>index_method</replaceable>.
      Each <replaceable class="parameter">exclude_element</replaceable>
      defines a column of the index, so it can optionally specify a collation,
      an operator class, operator class parameters, and/or ordering options;
      these are described fully under <xref linkend="sql-createindex"/>.
     </para>

     <para>
      The access method must support <literal>amgettuple</literal> (see <xref
      linkend="indexam"/>); at present this means <acronym>GIN</acronym>
      cannot be used.  Although it's allowed, there is little point in using
      B-tree or hash indexes with an exclusion constraint, because this
      does nothing that an ordinary unique constraint doesn't do better.
      So in practice the access method will always be <acronym>GiST</acronym> or
      <acronym>SP-GiST</acronym>.
     </para>

     <para>
      The <replaceable class="parameter">predicate</replaceable> allows you to specify an
      exclusion constraint on a subset of the table; internally this creates