</para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">new_constraint_name</replaceable></term>
      <listitem>
       <para>
        The new name for the constraint.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">new_owner</replaceable></term>
      <listitem>
       <para>
        The user name of the new owner of the domain.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">new_schema</replaceable></term>
      <listitem>
       <para>
        The new schema for the domain.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </para>
  </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   Although <command>ALTER DOMAIN ADD CONSTRAINT</command> attempts to verify
   that existing stored data satisfies the new constraint, this check is not
   bulletproof, because the command cannot <quote>see</quote> table rows that
   are newly inserted or updated and not yet committed.  If there is a hazard
   that concurrent operations might insert bad data, the way to proceed is to
   add the constraint using the <literal>NOT VALID</literal> option, commit
   that command, wait until all transactions started before that commit have
   finished, and then issue <command>ALTER DOMAIN VALIDATE
   CONSTRAINT</command> to search for data violating the constraint.  This
   method is reliable because once the constraint is committed, all new
   transactions are guaranteed to enforce it against new values of the domain
   type.
  </para>

  <para>
   Currently, <command>ALTER DOMAIN ADD CONSTRAINT</command>, <command>ALTER
   DOMAIN VALIDATE CONSTRAINT</command>, and <command>ALTER DOMAIN SET NOT
   NULL</command> will fail if the named domain or any derived domain is used
   within a container-type column (a composite, array, or range column) in
   any table in the database.  They should eventually be improved to be able
   to verify the new constraint for such nested values.
  </para>

 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   To add a <literal>NOT NULL</literal> constraint to a domain:
<programlisting>
ALTER DOMAIN zipcode SET NOT NULL;
</programlisting>
   To remove a <literal>NOT NULL</literal> constraint from a domain:
<programlisting>
ALTER DOMAIN zipcode DROP NOT NULL;
</programlisting>
  </para>

  <para>
   To add a check constraint to a domain:
<programlisting>
ALTER DOMAIN zipcode ADD CONSTRAINT zipchk CHECK (char_length(VALUE) = 5);
</programlisting>
  </para>

  <para>
   To remove a check constraint from a domain:
<programlisting>
ALTER DOMAIN zipcode DROP CONSTRAINT zipchk;
</programlisting>
  </para>

  <para>
   To rename a check constraint on a domain:
<programlisting>
ALTER DOMAIN zipcode RENAME CONSTRAINT zipchk TO zip_check;
</programlisting>
  </para>

  <para>
   To move the domain into a different schema:
<programlisting>
ALTER DOMAIN zipcode SET SCHEMA customers;
</programlisting></para>
 </refsect1>

 <refsect1 id="sql-alterdomain-compatibility">
  <title>Compatibility</title>

  <para>
   <command>ALTER DOMAIN</command> conforms to the <acronym>SQL</acronym>
   standard, except for the <literal>OWNER</literal>, <literal>RENAME</literal>, <literal>SET SCHEMA</literal>, and
   <literal>VALIDATE CONSTRAINT</literal> variants, which are
   <productname>PostgreSQL</productname> extensions.  The <literal>NOT VALID</literal>
   clause of the <literal>ADD CONSTRAINT</literal> variant is also a
   <productname>PostgreSQL</productname> extension.
  </para>
 </refsect1>

 <refsect1 id="sql-alterdomain-see-also">
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-createdomain"/></member>
   <member><xref linkend="sql-dropdomain"/></member>
  </simplelist>
 </refsect1>

</refentry>