searching the tree structure.
 </para>

 <para>
   This extensibility should not be confused with the extensibility of the
   other standard search trees in terms of the data they can handle.  For
   example, <productname>PostgreSQL</productname> supports extensible B-trees
   and hash indexes. That means that you can use
   <productname>PostgreSQL</productname> to build a B-tree or hash over any
   data type you want. But B-trees only support range predicates
   (<literal>&lt;</literal>, <literal>=</literal>, <literal>&gt;</literal>),
   and hash indexes only support equality queries.
 </para>

 <para>
   So if you index, say, an image collection with a
   <productname>PostgreSQL</productname> B-tree, you can only issue queries
   such as <quote>is imagex equal to imagey</quote>, <quote>is imagex less
   than imagey</quote> and <quote>is imagex greater than imagey</quote>.
   Depending on how you define <quote>equals</quote>, <quote>less than</quote>
   and <quote>greater than</quote> in this context, this could be useful.
   However, by using a <acronym>GiST</acronym> based index, you could create
   ways to ask domain-specific questions, perhaps <quote>find all images of
   horses</quote> or <quote>find all over-exposed images</quote>.
 </para>

 <para>
   All it takes to get a <acronym>GiST</acronym> access method up and running
   is to implement several user-defined methods, which define the behavior of
   keys in the tree. Of course these methods have to be pretty fancy to
   support fancy queries, but for all the standard queries (B-trees,
   R-trees, etc.) they're relatively straightforward. In short,
   <acronym>GiST</acronym> combines extensibility along with generality, code
   reuse, and a clean interface.
  </para>

 <para>
   There are five methods that an index operator class for
   <acronym>GiST</acronym> must provide, and seven that are optional.
   Correctness of the index is ensured
   by proper implementation of the <function>same</function>, <function>consistent</function>
   and <function>union</function> methods, while efficiency (size and speed) of the
   index will depend on the <function>penalty</function> and <function>picksplit</function>
   methods.
   Two optional methods are <function>compress</function> and
   <function>decompress</function>, which allow an index to have internal tree data of
   a different type than the data it indexes. The leaves are to be of the
   indexed data type, while the other tree nodes can be of any C struct (but
   you still have to follow <productname>PostgreSQL</productname> data type rules here,
   see about <literal>varlena</literal> for variable sized data). If the tree's
   internal data type exists at the SQL level, the <literal>STORAGE</literal> option
   of the <command>CREATE OPERATOR CLASS</command> command can be used.
   The optional eighth method is <function>distance</function>, which is needed
   if the operator class wishes to support ordered scans (nearest-neighbor
   searches). The optional ninth method <function>fetch</function> is needed if the
   operator class wishes to support index-only scans, except when the
   <function>compress</function> method is omitted. The optional tenth method
   <function>options</function> is needed if the operator class has
   user-specified parameters.
   The optional eleventh method <function>sortsupport</function> is used to
   speed up building a <acronym>GiST</acronym> index.
   The optional twelfth method <function>stratnum</function> is used to
   translate compare types (from
   <filename>src/include/nodes/primnodes.h</filename>) into strategy numbers
   used by the operator class.  This lets the core code look up operators for
   temporal constraint indexes.
 </para>

 <variablelist>
    <varlistentry>
     <term><function>consistent</function></term>
     <listitem>
      <para>
       Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
       this function determines whether