The negator of this operator.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">res_proc</replaceable></term>
      <listitem>
       <para>
        The restriction selectivity estimator function for this operator.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">join_proc</replaceable></term>
      <listitem>
       <para>
        The join selectivity estimator function for this operator.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>HASHES</literal></term>
      <listitem>
       <para>
       Indicates this operator can support a hash join.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>MERGES</literal></term>
      <listitem>
       <para>
       Indicates this operator can support a merge join.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

  <para>
   To give a schema-qualified operator name in <replaceable
   class="parameter">com_op</replaceable> or the other optional
   arguments, use the <literal>OPERATOR()</literal> syntax, for example:
<programlisting>
COMMUTATOR = OPERATOR(myschema.===) ,
</programlisting></para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   Refer to <xref linkend="xoper"/> and <xref linkend="xoper-optimization"/>
   for further information.
  </para>

  <para>
   When you are defining a self-commutative operator, you just do it.
   When you are defining a pair of commutative operators, things are
   a little trickier: how can the first one to be defined refer to the
   other one, which you haven't defined yet?  There are three solutions
   to this problem:

   <itemizedlist>
    <listitem>
     <para>
      One way is to omit the <literal>COMMUTATOR</literal> clause in the
      first operator that you define, and then provide one in the second
      operator's definition.  Since <productname>PostgreSQL</productname>
      knows that commutative operators come in pairs, when it sees the
      second definition it will automatically go back and fill in the
      missing <literal>COMMUTATOR</literal> clause in the first
      definition.
     </para>
    </listitem>

    <listitem>
     <para>
      Another, more straightforward way is just to
      include <literal>COMMUTATOR</literal> clauses in both definitions.
      When <productname>PostgreSQL</productname> processes the first
      definition and realizes that <literal>COMMUTATOR</literal> refers to
      a nonexistent operator, the system will make a dummy entry for that
      operator in the system catalog.  This dummy entry will have valid
      data only for the operator name, left and right operand types, and
      owner, since that's all that <productname>PostgreSQL</productname>
      can deduce at this point.  The first