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 definitions and check
   constraints down the inheritance hierarchy.  Again, dropping
   columns that are depended on by other tables is only possible when using
   the <literal>CASCADE</literal> option. <command>ALTER
   TABLE</command> follows the same rules for duplicate column merging
   and rejection that apply during <command>CREATE TABLE</command>.
  </para>

  <para>
   Inherited queries perform access permission checks on the parent table
   only.  Thus, for example, granting <literal>UPDATE</literal> permission on
   the <structname>cities</structname> table implies permission to update rows in
   the <structname>capitals</structname> table as well, when they are
   accessed through <structname>cities</structname>.  This preserves the appearance
   that the data is (also) in the parent table.  But
   the <structname>capitals</structname> table could not be updated directly
   without an additional grant.  In a similar way, the parent table's row
   security policies (see <xref linkend="ddl-rowsecurity"/>) are applied to
   rows coming from child tables during an inherited query.  A child table's
   policies, if any, are applied only when it is the table explicitly named
   in the query; and in that case, any policies attached to its parent(s) are
   ignored.
  </para>

  <para>
   Foreign tables (see <xref linkend="ddl-foreign-data"/>) can also
   be part of inheritance hierarchies, either as parent or child
   tables, just as regular tables can be.  If a foreign table is part
   of an inheritance hierarchy then any operations not supported by
   the foreign table are not supported on the whole hierarchy either.
  </para>

 <sect2 id="ddl-inherit-caveats">
  <title>Caveats</title>

  <para>
   Note that not all SQL commands are able to work on
   inheritance hierarchies.  Commands that are used for data querying,
   data modification, or schema modification
   (e.g., <literal>SELECT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,
   most variants of <literal>ALTER TABLE</literal>, but
   not <literal>INSERT</literal> or <literal>ALTER TABLE ...
   RENAME</literal>) typically default to including child tables and
   support the <literal>ONLY</literal> notation to exclude them.
   The majority of commands that do database maintenance and tuning
   (e.g., <literal>REINDEX</literal>) only work on individual, physical
   tables and do not support recursing over inheritance hierarchies.
   However, both <literal>VACUUM</literal> and <literal>ANALYZE</literal>
   commands default to including child tables and the <literal>ONLY</literal>
   notation is supported to allow them to be excluded.  The respective
   behavior of each individual command is documented in its reference page
   (<xref linkend="sql-commands"/>).
  </para>

  <para>
   A serious limitation of the inheritance feature is that indexes (including
   unique constraints) and foreign key constraints only apply to single
   tables, not to their inheritance children.