There is no effect on the stored data.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-altertable-desc-set-schema">
    <term><literal>SET SCHEMA</literal></term>
    <listitem>
     <para>
      This form moves the table into another schema.  Associated indexes,
      constraints, and sequences owned by table columns are moved as well.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-altertable-attach-partition">
    <term><literal>ATTACH PARTITION <replaceable class="parameter">partition_name</replaceable> { FOR VALUES <replaceable class="parameter">partition_bound_spec</replaceable> | DEFAULT }</literal></term>
    <listitem>
     <para>
      This form attaches an existing table (which might itself be partitioned)
      as a partition of the target table. The table can be attached
      as a partition for specific values using <literal>FOR VALUES</literal>
      or as a default partition by using <literal>DEFAULT</literal>.
      For each index in the target table, a corresponding
      one will be created in the attached table; or, if an equivalent
      index already exists, it will be attached to the target table's index,
      as if <command>ALTER INDEX ATTACH PARTITION</command> had been executed.
      Note that if the existing table is a foreign table, it is currently not
      allowed to attach the table as a partition of the target table if there
      are <literal>UNIQUE</literal> indexes on the target table.  (See also
      <xref linkend="sql-createforeigntable"/>.)  For each user-defined
      row-level trigger that exists in the target table, a corresponding one
      is created in the attached table.
     </para>

     <para>
      A partition using <literal>FOR VALUES</literal> uses same syntax for
      <replaceable class="parameter">partition_bound_spec</replaceable> as
      <link linkend="sql-createtable"><command>CREATE TABLE</command></link>.
      The partition bound specification
      must correspond to the partitioning strategy and partition key of the
      target table.  The table to be attached must have all the same columns
      as the target table and no more; moreover, the column types must also
      match.  Also, it must have all the <literal>NOT NULL</literal> and
      <literal>CHECK</literal> constraints of the target table, not marked
      <literal>NO INHERIT</literal>.  Currently
      <literal>FOREIGN KEY</literal> constraints are not considered.
      <literal>UNIQUE</literal> and <literal>PRIMARY KEY</literal> constraints
      from the parent table will be created in the partition, if they don't
      already exist.
     </para>

     <para>
      If the new partition is a regular table, a full table scan is performed
      to check that existing rows in the table do not violate the partition
      constraint. It is possible to avoid this scan by adding a valid
      <literal>CHECK</literal> constraint to the table that allows only
      rows satisfying the desired partition constraint before running this
      command. The <literal>CHECK</literal> constraint will be used to
      determine that the table need not be scanned to validate the partition
      constraint. This does not work, however, if any of the partition keys
      is an expression and the partition does not accept
      <literal>NULL</literal> values. If attaching a list partition that will
      not accept <literal>NULL</literal> values, also add a
      <literal>NOT NULL</literal> constraint to the partition key column,
      unless it's an expression.
     </para>

     <para>
      If the new partition is a foreign table, nothing is done to verify
      that all the rows in the foreign table obey the partition constraint.
      (See the discussion in <xref linkend="sql-createforeigntable"/> about
      constraints on the foreign table.)
     </para>

     <para>
      When a table has a default partition, defining a new partition changes
      the partition