</varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argument_type</replaceable></term>
    <listitem>
     <para>
      The parameter data type(s) of the function.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_name</replaceable></term>
    <listitem>
     <para>
      The new name of the operator family.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_owner</replaceable></term>
    <listitem>
     <para>
      The new owner of the operator family.
     </para>
    </listitem>
   </varlistentry>

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

  <para>
   The <literal>OPERATOR</literal> and <literal>FUNCTION</literal>
   clauses can appear in any order.
  </para>

 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   Notice that the <literal>DROP</literal> syntax only specifies the <quote>slot</quote>
   in the operator family, by strategy or support number and input data
   type(s).  The name of the operator or function occupying the slot is not
   mentioned.  Also, for <literal>DROP FUNCTION</literal> the type(s) to specify
   are the input data type(s) the function is intended to support; for
   GiST, SP-GiST and GIN indexes this might have nothing to do with the actual
   input argument types of the function.
  </para>

  <para>
   Because the index machinery does not check access permissions on functions
   before using them, including a function or operator in an operator family
   is tantamount to granting public execute permission on it.  This is usually
   not an issue for the sorts of functions that are useful in an operator
   family.
  </para>

  <para>
   The operators should not be defined by SQL functions.  An SQL function
   is likely to be