parent.
       </para>
      </listitem>

      <listitem>
       <para>
        Table inheritance allows for multiple inheritance.
       </para>
      </listitem>

      <listitem>
       <para>
        Declarative partitioning only supports range, list and hash
        partitioning, whereas table inheritance allows data to be divided in a
        manner of the user's choosing.  (Note, however, that if constraint
        exclusion is unable to prune child tables effectively, query performance
        might be poor.)
       </para>
      </listitem>
     </itemizedlist>
    </para>

    <sect3 id="ddl-partitioning-inheritance-example">
     <title>Example</title>

     <para>
      This example builds a partitioning structure equivalent to the
      declarative partitioning example above.  Use
      the following steps:

      <orderedlist spacing="compact">
       <listitem>
        <para>
         Create the <quote>root</quote> table, from which all of the
         <quote>child</quote> tables will inherit.  This table will contain no data.  Do not
         define any check constraints on this table, unless you intend them
         to be applied equally to all child tables.  There is no point in
         defining any indexes or unique constraints on it, either.  For our
         example, the root table is the <structname>measurement</structname>
         table as originally defined:

<programlisting>
CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
);
</programlisting>
        </para>
       </listitem>

       <listitem>
        <para>
         Create several <quote>child</quote> tables that each inherit from
         the root table.  Normally, these tables will not add any columns
         to the set inherited from the root.  Just as with declarative
         partitioning, these tables are in every way normal
         <productname>PostgreSQL</productname> tables (or foreign tables).
        </para>

        <para>
<programlisting>
CREATE TABLE measurement_y2006m02 () INHERITS (measurement);
CREATE TABLE measurement_y2006m03 () INHERITS (measurement);
...
CREATE TABLE measurement_y2007m11 () INHERITS (measurement);
CREATE TABLE measurement_y2007m12 () INHERITS (measurement);
CREATE TABLE measurement_y2008m01 () INHERITS (measurement);
</programlisting>
        </para>
       </listitem>

       <listitem>
        <para>
         Add non-overlapping table constraints to the child tables to
         define the allowed key values in each.
        </para>

        <para>
         Typical examples would be:
<programlisting>
CHECK ( x = 1 )
CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' ))
CHECK ( outletID &gt;= 100 AND outletID &lt; 200 )
</programlisting>
         Ensure that the constraints guarantee that there is no overlap
         between the key values permitted in different child tables.  A common
         mistake is to set up range constraints like:
<programlisting>
CHECK ( outletID BETWEEN 100 AND 200 )
CHECK ( outletID BETWEEN 200 AND 300 )
</programlisting>
         This is wrong since it is not clear which child table the key
         value 200 belongs in.
         Instead, ranges should be defined in this style:

<programlisting>
CREATE TABLE measurement_y2006m02 (
    CHECK ( logdate &gt;= DATE '2006-02-01' AND logdate &lt; DATE '2006-03-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2006m03 (
    CHECK ( logdate &gt;= DATE '2006-03-01' AND logdate &lt; DATE '2006-04-01' )
) INHERITS (measurement);

...
CREATE TABLE measurement_y2007m11 (
    CHECK ( logdate &gt;= DATE '2007-11-01' AND logdate &lt; DATE '2007-12-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2007m12 (
    CHECK ( logdate &gt;= DATE '2007-12-01' AND logdate &lt; DATE '2008-01-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2008m01 (
    CHECK ( logdate &gt;= DATE '2008-01-01' AND logdate &lt; DATE '2008-02-01'