the columns using the domain contain no null values.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>ADD <replaceable class="parameter">domain_constraint</replaceable> [ NOT VALID ]</literal></term>
    <listitem>
     <para>
      This form adds a new constraint to a domain.
      When a new constraint is added to a domain, all columns using that
      domain will be checked against the newly added constraint.  These
      checks can be suppressed by adding the new constraint using the
      <literal>NOT VALID</literal> option; the constraint can later be made
      valid using <command>ALTER DOMAIN ... VALIDATE CONSTRAINT</command>.
      Newly inserted or updated rows are always checked against all
      constraints, even those marked <literal>NOT VALID</literal>.
      <literal>NOT VALID</literal> is only accepted for <literal>CHECK</literal> constraints.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>DROP CONSTRAINT [ IF EXISTS ]</literal></term>
    <listitem>
     <para>
      This form drops constraints on a domain.
      If <literal>IF EXISTS</literal> is specified and the constraint
      does not exist, no error is thrown. In this case a notice is issued instead.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>RENAME CONSTRAINT</literal></term>
    <listitem>
     <para>
      This form changes the name of a constraint on a domain.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>VALIDATE CONSTRAINT</literal></term>
    <listitem>
     <para>
      This form validates a constraint previously added as
      <literal>NOT VALID</literal>, that is, it verifies that all values in
      table columns of the domain type satisfy the specified constraint.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>OWNER</literal></term>
    <listitem>
     <para>
      This form changes the owner of the domain to the specified user.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>RENAME</literal></term>
    <listitem>
     <para>
      This form changes the name of the domain.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>SET SCHEMA</literal></term>
    <listitem>
     <para>
      This form changes the schema of the domain.  Any constraints
      associated with the domain are moved into the new schema as well.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   You must own the domain to use <command>ALTER DOMAIN</command>.
   To change the schema of a domain, you must also have
   <literal>CREATE</literal> privilege on the new schema.
   To alter the owner, you must be able to <literal>SET ROLE</literal> to the
   new owning role, and that role must have <literal>CREATE</literal> privilege
   on the domain's schema.  (These restrictions enforce that altering the owner
   doesn't do anything you couldn't do by dropping and recreating the domain.
   However, a superuser can alter ownership of any domain anyway.)
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

   <para>
    <variablelist>
     <varlistentry>
      <term><replaceable class="parameter">name</replaceable></term>
      <listitem>
       <para>
        The name (possibly schema-qualified) of an existing domain to
        alter.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">domain_constraint</replaceable></term>
      <listitem>
       <para>
        New domain constraint for the domain.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">constraint_name</replaceable></term>
      <listitem>
       <para>
        Name of an existing constraint to drop or rename.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>