passing the
       resulting string to the input function of the target data type.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>AS ASSIGNMENT</literal></term>

     <listitem>
      <para>
       Indicates that the cast can be invoked implicitly in assignment
       contexts.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>AS IMPLICIT</literal></term>

     <listitem>
      <para>
       Indicates that the cast can be invoked implicitly in any context.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

  <para>
   Cast implementation functions can have one to three arguments.
   The first argument type must be identical to or binary-coercible from
   the cast's source type.  The second argument,
   if present, must be type <type>integer</type>; it receives the type
   modifier associated with the destination type, or <literal>-1</literal>
   if there is none.  The third argument,
   if present, must be type <type>boolean</type>; it receives <literal>true</literal>
   if the cast is an explicit cast, <literal>false</literal> otherwise.
   (Bizarrely, the SQL standard demands different behaviors for explicit and
   implicit casts in some cases.  This argument is supplied for functions
   that must implement such casts.  It is not recommended that you design
   your own data types so that this matters.)
  </para>

  <para>
   The return type of a cast function must be identical to or
   binary-coercible to the cast's target type.
  </para>

  <para>
   Ordinarily a cast must have different source and target data types.
   However, it is allowed to declare a cast with identical source and
   target types if it has a cast implementation function with more than one
   argument.  This is used to represent type-specific length coercion
   functions in the system catalogs.  The named function is used to
   coerce a value of the type to the type modifier value given by its
   second argument.
  </para>

  <para>
   When a cast has different source and
   target types and a function that takes more than one argument, it
   supports converting from one type to another and applying a length
   coercion in a single step.  When no such entry is available, coercion
   to a type that uses a type modifier involves two cast steps, one to
   convert between data types and a second to apply the modifier.
  </para>

  <para>
   A cast to or from a domain type currently has no effect.  Casting
   to or from a domain uses the casts associated with its underlying type.
  </para>

 </refsect1>

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

  <para>
   Use <link linkend="sql-dropcast"><command>DROP CAST</command></link> to remove user-defined casts.
  </para>

  <para>
   Remember that if you want to be able to convert types both ways you
   need to declare casts both ways explicitly.
  </para>

 <indexterm zone="sql-createcast">
  <primary>cast</primary>
  <secondary>I/O conversion</secondary>
 </indexterm>

  <para>
   It is normally not necessary to create casts between user-defined types
   and the standard string types (<type>text</type>, <type>varchar</type>, and
   <type>char(<replaceable>n</replaceable>)</type>, as well as user-defined types that
   are defined to be in the string category).  <productname>PostgreSQL</productname>
   provides automatic I/O conversion casts for that. The automatic casts to
   string types are treated as assignment casts, while the automatic casts
   from string types are
   explicit-only.  You can override this behavior by declaring your own
   cast to replace an automatic cast, but usually the only reason to
   do so is if you want the conversion to be more easily invokable than the
   standard assignment-only or explicit-only setting.  Another possible
   reason