that there is no simple
         way to force an error if the set of rules doesn't cover the insertion
         date; the data will silently go into the root table instead.
        </para>
       </listitem>

       <listitem>
        <para>
         Ensure that the <xref linkend="guc-constraint-exclusion"/>
         configuration parameter is not disabled in
         <filename>postgresql.conf</filename>; otherwise
         child tables may be accessed unnecessarily.
        </para>
       </listitem>
      </orderedlist>
     </para>

     <para>
      As we can see, a complex table hierarchy could require a
      substantial amount of DDL.  In the above example we would be creating
      a new child table each month, so it might be wise to write a script that
      generates the required DDL automatically.
     </para>
    </sect3>

    <sect3 id="ddl-partitioning-inheritance-maintenance">
     <title>Maintenance for Inheritance Partitioning</title>
     <para>
      To remove old data quickly, simply drop the child table that is no longer
      necessary:
<programlisting>
DROP TABLE measurement_y2006m02;
</programlisting>
     </para>

    <para>
     To remove the child table from the inheritance hierarchy table but retain access to
     it as a table in its own right:

<programlisting>
ALTER TABLE measurement_y2006m02 NO INHERIT measurement;
</programlisting>
    </para>

    <para>
     To add a new child table to handle new data, create an empty child table
     just as the original children were created above:

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

     Alternatively, one may want to create and populate the new child table
     before adding it to the table hierarchy.  This could allow data to be
     loaded, checked, and transformed before being made visible to queries on
     the parent table.

<programlisting>
CREATE TABLE measurement_y2008m02
  (LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
ALTER TABLE measurement_y2008m02 ADD CONSTRAINT y2008m02
   CHECK ( logdate &gt;= DATE '2008-02-01' AND logdate &lt; DATE '2008-03-01' );
\copy measurement_y2008m02 from 'measurement_y2008m02'
-- possibly some other data preparation work
ALTER TABLE measurement_y2008m02 INHERIT measurement;
</programlisting>
    </para>
   </sect3>

   <sect3 id="ddl-partitioning-inheritance-caveats">
    <title>Caveats</title>

    <para>
     The following caveats apply to partitioning implemented using
     inheritance:
     <itemizedlist>
      <listitem>
       <para>
        There is no automatic way to verify that all of the
        <literal>CHECK</literal> constraints are mutually
        exclusive.  It is safer to create code that generates
        child tables and creates and/or modifies associated objects than
        to write each by hand.
       </para>
      </listitem>

      <listitem>
       <para>
        Indexes and foreign key constraints apply to single tables and not
        to their inheritance children, hence they have some
        <link linkend="ddl-inherit-caveats">caveats</link> to be aware of.
       </para>
      </listitem>

      <listitem>
       <para>
        The schemes shown here assume that the values of a row's key column(s)
        never change, or at least do not change enough to require it to move to another partition.
        An <command>UPDATE</command> that attempts
        to do that will fail because of the <literal>CHECK</literal> constraints.
        If you need to handle such cases, you can put suitable update triggers
        on the child tables, but it makes management of the structure
        much more complicated.
       </para>
      </listitem>

      <listitem>
       <para>
        Manual <command>VACUUM</command> and <command>ANALYZE</command>
        commands will automatically process all inheritance child tables.  If
        this is