Home • Explore • Blog • CI
☰



postgresql
3rd chunk of `doc/src/sgml/ref/alter_domain.sgml`
f60efbd11bf70347953f8f615ea24c046177cdc428073d780000000100000b8d
 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>
      <term><literal>NOT VALID</literal></term>
      <listitem>
       <para>
        Do not verify existing stored data for constraint validity.
       </para>
      </listitem>
     </varlistentry>


     <varlistentry>
      <term><literal>CASCADE</literal></term>
      <listitem>
       <para>
        Automatically drop objects that depend on the constraint,
        and in turn all objects that depend on those objects
        (see <xref linkend="ddl-depend"/>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>RESTRICT</literal></term>
      <listitem>
       <para>
        Refuse to drop the constraint if there are any dependent
        objects. This is the default behavior.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">new_name</replaceable></term>
      <listitem>
       <para>
        The new name for the domain.
       </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,
Title: ALTER DOMAIN - Parameters and Notes
Summary
This section continues the documentation for the ALTER DOMAIN command, focusing on the parameters involved in altering domains and constraints. It details parameters like the domain name, domain constraint, constraint name, NOT VALID option, CASCADE and RESTRICT options for dropping constraints, new names for domains and constraints, the new owner, and the new schema. It concludes with a note about the limitations of the constraint verification process when adding new constraints.