clause can
      be used to override the parameters of the sequence.  The available
      options include those shown for <xref linkend="sql-createsequence"/>,
      plus <literal>SEQUENCE NAME <replaceable>name</replaceable></literal>,
      <literal>LOGGED</literal>, and <literal>UNLOGGED</literal>, which
      allow selection of the name and persistence level of the
      sequence.  Without <literal>SEQUENCE NAME</literal>, the system
      chooses an unused name for the sequence.
      Without <literal>LOGGED</literal> or <literal>UNLOGGED</literal>,
      the sequence will have the same persistence level as the table.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-unique">
    <term><literal>UNIQUE [ NULLS [ NOT ] DISTINCT ]</literal> (column constraint)</term>
    <term><literal>UNIQUE [ NULLS [ NOT ] DISTINCT ] ( <replaceable class="parameter">column_name</replaceable> [, ... ] [, <replaceable class="parameter">column_name</replaceable> WITHOUT OVERLAPS ] )</literal>
    <optional> <literal>INCLUDE ( <replaceable class="parameter">column_name</replaceable> [, ...])</literal> </optional> (table constraint)</term>

    <listitem>
     <para>
      The <literal>UNIQUE</literal> constraint specifies that a
      group of one or more columns of a table can contain
      only unique values. The behavior of a unique table constraint
      is the same as that of a unique column constraint, with the
      additional capability to span multiple columns.  The constraint
      therefore enforces that any two rows must differ in at least one
      of these columns.
     </para>

     <para>
      If the <literal>WITHOUT OVERLAPS</literal> option is specified for the
      last column, then that column is checked for overlaps instead of
      equality.  In that case, the other columns of the constraint will allow
      duplicates so long as the duplicates don't overlap in the
      <literal>WITHOUT OVERLAPS</literal> column.  (This is sometimes called a
      temporal key, if the column is a range of dates or timestamps, but
      <productname>PostgreSQL</productname> allows ranges over any base type.)
      In effect, such a constraint is enforced with an <literal>EXCLUDE</literal>
      constraint rather than a <literal>UNIQUE</literal> constraint.  So for
      example <literal>UNIQUE (id, valid_at WITHOUT OVERLAPS)</literal> behaves
      like <literal>EXCLUDE USING GIST (id WITH =, valid_at WITH
      &amp;&amp;)</literal>.  The <literal>WITHOUT OVERLAPS</literal> column
      must have a range or multirange type.  Empty ranges/multiranges are
      not permitted.  The non-<literal>WITHOUT OVERLAPS</literal> columns of
      the constraint can be any type that can be compared for equality in a
      GiST index.  By default, only range types are supported, but you can use
      other types by adding the <xref linkend="btree-gist"/> extension (which
      is the expected way to use this feature).
     </para>

     <para>
      For the purpose of a unique constraint, null values are not
      considered equal, unless <literal>NULLS NOT DISTINCT</literal> is
      specified.
     </para>

     <para>
      Each unique constraint should name a set of columns that is
      different from the set of columns named by any other unique or
      primary key constraint defined for the table.  (Otherwise, redundant
      unique constraints will be discarded.)
     </para>

     <para>
      When establishing a unique constraint for a multi-level partition
      hierarchy, all the columns in the partition key of the target
      partitioned table, as well as those of all its descendant partitioned
      tables, must be included in the constraint definition.
     </para>

     <para>
      Adding a unique constraint will automatically create a unique btree
      index on the column or group of columns used in the constraint.  But if
      the constraint includes a <literal>WITHOUT OVERLAPS</literal>