CONSTRAINT</literal> in cases where the table is known to contain
pre-existing violations. Once the constraint is in place, no new
violations can be inserted, and the existing problems can be corrected
at leisure until <literal>VALIDATE CONSTRAINT</literal> finally
succeeds.
</para>
<para>
The <literal>DROP COLUMN</literal> form does not physically remove
the column, but simply makes it invisible to SQL operations. Subsequent
insert and update operations in the table will store a null value for the
column. Thus, dropping a column is quick but it will not immediately
reduce the on-disk size of your table, as the space occupied
by the dropped column is not reclaimed. The space will be
reclaimed over time as existing rows are updated.
</para>
<para>
To force immediate reclamation of space occupied by a dropped column,
you can execute one of the forms of <command>ALTER TABLE</command> that
performs a rewrite of the whole table. This results in reconstructing
each row with the dropped column replaced by a null value.
</para>
<para>
The rewriting forms of <command>ALTER TABLE</command> are not MVCC-safe.
After a table rewrite, the table will appear empty to concurrent
transactions, if they are using a snapshot taken before the rewrite
occurred. See <xref linkend="mvcc-caveats"/> for more details.
</para>
<para>
The <literal>USING</literal> option of <literal>SET DATA TYPE</literal> can actually
specify any expression involving the old values of the row; that is, it
can refer to other columns as well as the one being converted. This allows
very general conversions to be done with the <literal>SET DATA TYPE</literal>
syntax. Because of this flexibility, the <literal>USING</literal>
expression is not applied to the column's default value (if any); the
result might not be a constant expression as required for a default.
This means that when there is no implicit or assignment cast from old to
new type, <literal>SET DATA TYPE</literal> might fail to convert the default even
though a <literal>USING</literal> clause is supplied. In such cases,
drop the default with <literal>DROP DEFAULT</literal>, perform the <literal>ALTER
TYPE</literal>, and then use <literal>SET DEFAULT</literal> to add a suitable new
default. Similar considerations apply to indexes and constraints involving
the column.
</para>
<para>
If a table has any descendant tables, it is not permitted to add,
rename, or change the type of a column in the parent table without doing
the same to the descendants. This ensures that the descendants always
have columns matching the parent. Similarly, a <literal>CHECK</literal>
constraint cannot be renamed in the parent without also renaming it in
all descendants, so that <literal>CHECK</literal> constraints also match
between the parent and its descendants. (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