(That restriction does not apply
    to index-based constraints, however.)
    Also, because selecting from the parent also selects from its descendants,
    a constraint on the parent cannot be marked valid unless it is also marked
    valid for those descendants.  In all of these cases, <command>ALTER TABLE
    ONLY</command> will be rejected.
   </para>

   <para>
    A recursive <literal>DROP COLUMN</literal> operation will remove a
    descendant table's column only if the descendant does not inherit
    that column from any other parents and never had an independent
    definition of the column.  A nonrecursive <literal>DROP
    COLUMN</literal> (i.e., <command>ALTER TABLE ONLY ... DROP
    COLUMN</command>) never removes any descendant columns, but
    instead marks them as independently defined rather than inherited.
    A nonrecursive <literal>DROP COLUMN</literal> command will fail for a
    partitioned table, because all partitions of a table must have the same
    columns as the partitioning root.
   </para>

   <para>
    The actions for identity columns (<literal>ADD
    GENERATED</literal>, <literal>SET</literal> etc., <literal>DROP
    IDENTITY</literal>), as well as the actions
    <literal>CLUSTER</literal>, <literal>OWNER</literal>,
    and <literal>TABLESPACE</literal> never recurse to descendant tables;
    that is, they always act as though <literal>ONLY</literal> were specified.
    Actions affecting trigger states recurse to partitions of partitioned
    tables (unless <literal>ONLY</literal> is specified), but never to
    traditional-inheritance descendants.
    Adding a constraint recurses only for <literal>CHECK</literal> constraints
    that are not marked <literal>NO INHERIT</literal>.
   </para>

   <para>
    Changing any part of a system catalog table is not permitted.
   </para>

   <para>
    Refer to <xref linkend="sql-createtable"/> for a further description of valid
    parameters. <xref linkend="ddl"/> has further information on
    inheritance.
   </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   To add a column of type <type>varchar</type> to a table:
<programlisting>
ALTER TABLE distributors ADD COLUMN address varchar(30);
</programlisting>
   That will cause all existing rows in the table to be filled with null
   values for the new column.
  </para>

  <para>
   To add a column with a non-null default:
<programlisting>
ALTER TABLE measurements
  ADD COLUMN mtime timestamp with time zone DEFAULT now();
</programlisting>
   Existing rows will be filled with the current time as the value of the
   new column, and then new rows will receive the time of their insertion.
  </para>

  <para>
   To add a column and fill it with a value different from the default to
   be used later:
<programlisting>
ALTER TABLE transactions
  ADD COLUMN status varchar(30) DEFAULT 'old',
  ALTER COLUMN status SET default 'current';
</programlisting>
   Existing rows will be filled with <literal>old</literal>, but then
   the default for subsequent commands will be <literal>current</literal>.
   The effects are the same as if the two sub-commands had been issued
   in separate <command>ALTER TABLE</command> commands.
  </para>

  <para>
   To drop a column from a table:
<programlisting>
ALTER TABLE distributors DROP COLUMN address RESTRICT;
</programlisting>
  </para>

  <para>
   To change the types of two existing columns in one operation:
<programlisting>
ALTER TABLE distributors
    ALTER COLUMN address TYPE varchar(80),
    ALTER COLUMN name TYPE varchar(100);
</programlisting>
  </para>

  <para>
   To change an integer column containing Unix timestamps to <type>timestamp
   with time zone</type> via a <literal>USING</literal> clause:
<programlisting>
ALTER TABLE foo
    ALTER COLUMN foo_timestamp SET DATA TYPE timestamp with time zone
    USING
        timestamp with time zone 'epoch' + foo_timestamp * interval '1 second';
</programlisting>
  </para>

  <para>
   The same, when the