ATTACH PARTITION measurement_usls_200602_idx;
...
</programlisting>

     This technique can be used with <literal>UNIQUE</literal> and
     <literal>PRIMARY KEY</literal> constraints too; the indexes are created
     implicitly when the constraint is created.  Example:
<programlisting>
ALTER TABLE ONLY measurement ADD UNIQUE (city_id, logdate);

ALTER TABLE measurement_y2006m02 ADD UNIQUE (city_id, logdate);
ALTER INDEX measurement_city_id_logdate_key
    ATTACH PARTITION measurement_y2006m02_city_id_logdate_key;
...
</programlisting>
    </para>
   </sect3>

   <sect3 id="ddl-partitioning-declarative-limitations">
    <title>Limitations</title>

   <para>
    The following limitations apply to partitioned tables:
    <itemizedlist>
     <listitem>
      <para>
       To create a unique or primary key constraint on a partitioned table,
       the partition keys must not include any expressions or function calls
       and the constraint's columns must include all of the partition key
       columns.  This limitation exists because the individual indexes making
       up the constraint can only directly enforce uniqueness within their own
       partitions; therefore, the partition structure itself must guarantee
       that there are not duplicates in different partitions.
      </para>
     </listitem>

     <listitem>
      <para>
       Similarly an exclusion constraint must include all the
       partition key columns. Furthermore the constraint must compare those
       columns for equality (not e.g. <literal>&amp;&amp;</literal>).
       Again, this limitation stems from not being able to enforce
       cross-partition restrictions. The constraint may include additional
       columns that aren't part of the partition key, and it may compare
       those with any operators you like.
      </para>
     </listitem>

     <listitem>
      <para>
       <literal>BEFORE ROW</literal> triggers on <literal>INSERT</literal>
       cannot change which partition is the final destination for a new row.
      </para>
     </listitem>

     <listitem>
      <para>
       Mixing temporary and permanent relations in the same partition tree is
       not allowed.  Hence, if the partitioned table is permanent, so must be
       its partitions and likewise if the partitioned table is temporary.  When
       using temporary relations, all members of the partition tree have to be
       from the same session.
      </para>
     </listitem>
    </itemizedlist>
    </para>

    <para>
     Individual partitions are linked to their partitioned table using
     inheritance behind-the-scenes.  However, it is not possible to use
     all of the generic features of inheritance with declaratively
     partitioned tables or their partitions, as discussed below.  Notably,
     a partition cannot have any parents other than the partitioned table
     it is a partition of, nor can a table inherit from both a partitioned
     table and a regular table.  That means partitioned tables and their
     partitions never share an inheritance hierarchy with regular tables.
    </para>

    <para>
     Since a partition hierarchy consisting of the partitioned table and its
     partitions is still an inheritance hierarchy,
     <structfield>tableoid</structfield> and all the normal rules of
     inheritance apply as described in <xref linkend="ddl-inherit"/>, with
     a few exceptions:

     <itemizedlist>
      <listitem>
       <para>
        Partitions cannot have columns that are not present in the parent.  It
        is not possible to specify columns when creating partitions with
        <command>CREATE TABLE</command>, nor is it possible to add columns to
        partitions after-the-fact using <command>ALTER TABLE</command>.
        Tables may be added as a partition with <command>ALTER TABLE
        ... ATTACH PARTITION</command> only if their columns exactly match
        the parent.
       </para>
      </listitem>

      <listitem>
       <para>