BY x RANGE BETWEEN 5 PRECEDING AND 10 FOLLOWING)
  FROM mytable;
</programlisting>
   it is not sufficient to know how to order by <literal>x</literal>;
   the database must also understand how to <quote>subtract 5</quote> or
   <quote>add 10</quote> to the current row's value of <literal>x</literal>
   to identify the bounds of the current window frame.  Comparing the
   resulting bounds to other rows' values of <literal>x</literal> is
   possible using the comparison operators provided by the B-tree operator
   class that defines the <literal>ORDER BY</literal> ordering &mdash; but
   addition and subtraction operators are not part of the operator class, so
   which ones should be used?  Hard-wiring that choice would be undesirable,
   because different sort orders (different B-tree operator classes) might
   need different behavior.  Therefore, a B-tree operator class can specify
   an <firstterm>in_range</firstterm> support function that encapsulates the
   addition and subtraction behaviors that make sense for its sort order.
   It can even provide more than one in_range support function, in case
   there is more than one data type that makes sense to use as the offset
   in <literal>RANGE</literal> clauses.
   If the B-tree operator class associated with the window's <literal>ORDER
   BY</literal> clause does not have a matching in_range support function,
   the <literal>RANGE</literal> <replaceable>offset</replaceable>
   <literal>PRECEDING</literal>/<literal>FOLLOWING</literal>
   option is not supported.
  </para>

  <para>
   Another important point is that an equality operator that
   appears in a hash operator family is a candidate for hash joins,
   hash aggregation, and related optimizations.  The hash operator family
   is essential here since it identifies the hash function(s) to use.
  </para>
 </sect2>

 <sect2 id="xindex-ordering-ops">
  <title>Ordering Operators</title>

  <para>
   Some index access methods (currently, only GiST and SP-GiST) support the concept of
   <firstterm>ordering operators</firstterm>.  What we have been discussing so far
   are <firstterm>search operators</firstterm>.  A search operator is one for which
   the index can be searched to find all rows satisfying
   <literal>WHERE</literal>
   <replaceable>indexed_column</replaceable>
   <replaceable>operator</replaceable>
   <replaceable>constant</replaceable>.
   Note that nothing is promised about the order in which the matching rows
   will be returned.  In contrast, an ordering operator does not restrict the
   set of rows that can be returned, but instead determines their order.
   An ordering operator is one for which the index can be scanned to return
   rows in the order represented by
   <literal>ORDER BY</literal>
   <replaceable>indexed_column</replaceable>
   <replaceable>operator</replaceable>
   <replaceable>constant</replaceable>.
   The reason for defining ordering operators that way is that it supports
   nearest-neighbor searches, if the operator is one that measures distance.
   For example, a query like
<programlisting><![CDATA[
SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
]]>
</programlisting>
   finds the ten places closest to a given target point.  A GiST index
   on the location column can do this efficiently because
   <literal>&lt;-&gt;</literal> is an ordering operator.
  </para>

  <para>
   While search operators have to return Boolean results, ordering operators
   usually return some other type, such as float or numeric for distances.
   This type is normally not the same as the data type being indexed.
   To avoid hard-wiring assumptions about the behavior of different data
   types, the definition of an ordering operator is required to name
   a B-tree operator family that specifies the sort ordering of the result
   data type.  As was stated in the previous section, B-tree operator families
   define <productname>PostgreSQL</productname>'s notion of ordering, so
   this is a