<programlisting>
INSERT INTO cities (name, population, elevation, state)
VALUES ('Albany', NULL, NULL, 'NY');
</programlisting>
   We might hope that the data would somehow be routed to the
   <structname>capitals</structname> table, but this does not happen:
   <command>INSERT</command> always inserts into exactly the table
   specified.  In some cases it is possible to redirect the insertion
   using a rule (see <xref linkend="rules"/>).  However that does not
   help for the above case because the <structname>cities</structname> table
   does not contain the column <structfield>state</structfield>, and so the
   command will be rejected before the rule can be applied.
  </para>

  <para>
   All check constraints and not-null constraints on a parent table are
   automatically inherited by its children, unless explicitly specified
   otherwise with <literal>NO INHERIT</literal> clauses.  Other types of constraints
   (unique, primary key, and foreign key constraints) are not inherited.
  </para>

  <para>
   A table can inherit from more than one parent table, in which case it has
   the union of the columns defined by the parent tables.  Any columns
   declared in the child table's definition are added to these.  If the
   same column name appears in multiple parent tables, or in both a parent
   table and the child's definition, then these columns are <quote>merged</quote>
   so that there is only one such column in the child table.  To be merged,
   columns must have the same data types, else an error is raised.
   Inheritable check constraints and not-null constraints are merged in a
   similar fashion.  Thus, for example, a merged column will be marked
   not-null if any one of the column definitions it came from is marked
   not-null.  Check constraints are merged if they have the same name,
   and the merge will fail if their conditions are different.
  </para>

  <para>
   Table inheritance is typically established when the child table is
   created, using the <literal>INHERITS</literal> clause of the
   <link linkend="sql-createtable"><command>CREATE TABLE</command></link>
   statement.
   Alternatively, a table which is already defined in a compatible way can
   have a new parent relationship added, using the <literal>INHERIT</literal>
   variant of <link linkend="sql-altertable"><command>ALTER TABLE</command></link>.
   To do this the new child table must already include columns with
   the same names and types as the columns of the parent. It must also include
   check constraints with the same names and check expressions as those of the
   parent. Similarly an inheritance link can be removed from a child using the
   <literal>NO INHERIT</literal> variant of <command>ALTER TABLE</command>.
   Dynamically adding and removing inheritance links like this can be useful
   when the inheritance relationship is being used for table
   partitioning (see <xref linkend="ddl-partitioning"/>).
  </para>

  <para>
   One convenient way to create a compatible table that will later be made
   a new child is to use the <literal>LIKE</literal> clause in <command>CREATE
   TABLE</command>. This creates a new table with the same columns as
   the source table. If there are any <literal>CHECK</literal>
   constraints defined on the source table, the <literal>INCLUDING
   CONSTRAINTS</literal> option to <literal>LIKE</literal> should be
   specified, as the new child must have constraints matching the parent
   to be considered compatible.
  </para>

  <para>
   A parent table cannot be dropped while any of its children remain. Neither
   can columns or check constraints of child tables be dropped or altered
   if they are inherited
   from any parent tables. If you wish to remove a table and all of its
   descendants, one easy way is to drop the parent table with the
   <literal>CASCADE</literal> option (see <xref linkend="ddl-depend"/>).
  </para>

  <para>
   <command>ALTER TABLE</command> will
   propagate any changes in column data