id="sql-altertable-parms-new-access-method">
      <term><replaceable class="parameter">new_access_method</replaceable></term>
      <listitem>
       <para>
        The name of the access method to which the table will be converted.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-altertable-parms-new-tablespace">
      <term><replaceable class="parameter">new_tablespace</replaceable></term>
      <listitem>
       <para>
        The name of the tablespace to which the table will be moved.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-altertable-parms-new-schema">
      <term><replaceable class="parameter">new_schema</replaceable></term>
      <listitem>
       <para>
        The name of the schema to which the table will be moved.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-altertable-parms-partition-name">
      <term><replaceable class="parameter">partition_name</replaceable></term>
      <listitem>
       <para>
        The name of the table to attach as a new partition or to detach from this table.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-altertable-parms-partition-bound-spec">
      <term><replaceable class="parameter">partition_bound_spec</replaceable></term>
      <listitem>
       <para>
        The partition bound specification for a new partition.  Refer to
        <xref linkend="sql-createtable"/> for more details on the syntax of the same.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
 </refsect1>

 <refsect1 id="sql-altertable-notes" xreflabel="Notes">
  <title>Notes</title>

   <para>
    The key word <literal>COLUMN</literal> is noise and can be omitted.
   </para>

   <para>
    When a column is added with <literal>ADD COLUMN</literal> and a
    non-volatile <literal>DEFAULT</literal> is specified, the default value is
    evaluated at the time of the statement and the result stored in the
    table's metadata, where it will be returned when any existing rows are
    accessed.  The value will be only applied when the table is rewritten,
    making the <command>ALTER TABLE</command> very fast even on large tables.
    If no column constraints are specified, NULL is used as the
    <literal>DEFAULT</literal>.  In neither case is a rewrite of the table
    required.
   </para>

   <para>
    Adding a column with a volatile <literal>DEFAULT</literal>
    (e.g., <function>clock_timestamp()</function>), a stored generated column,
    an identity column, or a column with a domain data type that has
    constraints will cause the entire table and its indexes to be rewritten.
    Adding a virtual generated column never requires a rewrite.
   </para>

   <para>
    Changing the type of an existing column will normally cause the entire table
    and its indexes to be rewritten.
    As an exception, when changing the type of an existing column,
    if the <literal>USING</literal> clause does not change the column
    contents and the old type is either binary coercible to the new type
    or an unconstrained domain over the new type, a table rewrite is not
    needed.  However, indexes will still be rebuilt unless the system
    can verify that the new index would be logically equivalent to the
    existing one.  For example, if the collation for a column has been
    changed, an index rebuild is required because the new sort
    order might be different.  However, in the absence of a collation
    change, a column can be changed from <type>text</type> to
    <type>varchar</type> (or vice versa) without rebuilding the indexes
    because these data types sort identically.
   </para>

   <para>
    Table and/or index
    rebuilds may take a significant amount of time for a large table,
    and will temporarily require as much as double the disk space.
   </para>

   <para>
    Adding an enforced <literal>CHECK</literal> or <literal>NOT NULL</literal>