as part of the operator class rather
   than as loose members of the family.
  </para>

  <para>
   In a B-tree operator family, all the operators in the family must sort
   compatibly, as is specified in detail in <xref linkend="btree-behavior"/>.
   For each
   operator in the family there must be a support function having the same
   two input data types as the operator.  It is recommended that a family be
   complete, i.e., for each combination of data types, all operators are
   included.  Each operator class should include just the non-cross-type
   operators and support function for its data type.
  </para>

  <para>
   To build a multiple-data-type hash operator family, compatible hash
   support functions must be created for each data type supported by the
   family.  Here compatibility means that the functions are guaranteed to
   return the same hash code for any two values that are considered equal
   by the family's equality operators, even when the values are of different
   types.  This is usually difficult to accomplish when the types have
   different physical representations, but it can be done in some cases.
   Furthermore, casting a value from one data type represented in the operator
   family to another data type also represented in the operator family via
   an implicit or binary coercion cast must not change the computed hash value.
   Notice that there is only one support function per data type, not one
   per equality operator.  It is recommended that a family be complete, i.e.,
   provide an equality operator for each combination of data types.
   Each operator class should include just the non-cross-type equality
   operator and the support function for its data type.
  </para>

  <para>
   GiST, SP-GiST, and GIN indexes do not have any explicit notion of
   cross-data-type operations.  The set of operators supported is just
   whatever the primary support functions for a given operator class can
   handle.
  </para>

  <para>
   In BRIN, the requirements depends on the framework that provides the
   operator classes.  For operator classes based on <literal>minmax</literal>,
   the behavior required is the same as for B-tree operator families:
   all the operators in the family must sort compatibly, and casts must
   not change the associated sort ordering.
  </para>

  <note>
   <para>
    Prior to <productname>PostgreSQL</productname> 8.3, there was no concept
    of operator families, and so any cross-data-type operators intended to be
    used with an index had to be bound directly into the index's operator
    class.  While this approach still works, it is deprecated because it
    makes an index's dependencies too broad, and because the planner can
    handle cross-data-type comparisons more effectively when both data types
    have operators in the same operator family.
   </para>
  </note>
 </sect2>

 <sect2 id="xindex-opclass-dependencies">
  <title>System Dependencies on Operator Classes</title>

   <indexterm>
    <primary>ordering operator</primary>
   </indexterm>

  <para>
   <productname>PostgreSQL</productname> uses operator classes to infer the
   properties of operators in more ways than just whether they can be used
   with indexes.  Therefore, you might want to create operator classes
   even if you have no intention of indexing any columns of your data type.
  </para>

  <para>
   In particular, there are SQL features such as <literal>ORDER BY</literal> and
   <literal>DISTINCT</literal> that require comparison and sorting of values.
   To implement these features on a user-defined data type,
   <productname>PostgreSQL</productname> looks for the default B-tree operator
   class for the data type.  The <quote>equals</quote> member of this operator
   class defines the system's notion of equality of values for
   <literal>GROUP BY</literal> and <literal>DISTINCT</literal>, and the sort ordering
   imposed by the operator class defines the default <literal>ORDER BY</literal>
   ordering.