values to be stored.  The consistent methods receive query
       <structfield>scankeys</structfield> unchanged, without transformation
       using <function>compress</function>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><function>options</function></term>
     <listitem>
      <para>
       Defines a set of user-visible parameters that control operator class
       behavior.
      </para>

      <para>
        The <acronym>SQL</acronym> declaration of the function must look like this:

<programlisting>
CREATE OR REPLACE FUNCTION my_options(internal)
RETURNS void
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;
</programlisting>
      </para>

      <para>
       The function is passed a pointer to a <structname>local_relopts</structname>
       struct, which needs to be filled with a set of operator class
       specific options.  The options can be accessed from other support
       functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
       <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
      </para>

      <para>
       Since the representation of the key in <acronym>SP-GiST</acronym> is
       flexible, it may depend on user-specified parameters.
      </para>
     </listitem>
    </varlistentry>
  </variablelist>

  <para>
   All the SP-GiST support methods are normally called in a short-lived
   memory context; that is, <varname>CurrentMemoryContext</varname> will be reset
   after processing of each tuple.  It is therefore not very important to
   worry about pfree'ing everything you palloc.  (The <function>config</function>
   method is an exception: it should try to avoid leaking memory.  But
   usually the <function>config</function> method need do nothing but assign
   constants into the passed parameter struct.)
  </para>

  <para>
   If the indexed column is of a collatable data type, the index collation
   will be passed to all the support methods, using the standard
   <function>PG_GET_COLLATION()</function> mechanism.
  </para>

</sect2>

<sect2 id="spgist-implementation">
 <title>Implementation</title>

  <para>
   This section covers implementation details and other tricks that are
   useful for implementers of <acronym>SP-GiST</acronym> operator classes to
   know.
  </para>

 <sect3 id="spgist-limits">
  <title>SP-GiST Limits</title>

  <para>
   Individual leaf tuples and inner tuples must fit on a single index page
   (8kB by default).  Therefore, when indexing values of variable-length
   data types, long values can only be supported by methods such as radix
   trees, in which each level of the tree includes a prefix that is short
   enough to fit on a page, and the final leaf level includes a suffix also
   short enough to fit on a page.  The operator class should set
   <structfield>longValuesOK</structfield> to true only if it is prepared to arrange for
   this to happen.  Otherwise, the <acronym>SP-GiST</acronym> core will
   reject any request to index a value that is too large to fit
   on an index page.
  </para>

  <para>
   Likewise, it is the operator class's responsibility that inner tuples
   do not grow too large to fit on an index page; this limits the number
   of child nodes that can be used in one inner tuple, as well as the
   maximum size of a prefix value.
  </para>

  <para>
   Another limitation is that when an inner tuple's node points to a set
   of leaf tuples, those tuples must all be in the same index page.
   (This is a design decision to reduce seeking and save space in the
   links that chain such tuples together.)  If the set of leaf tuples
   grows too large for a page, a split is performed and an intermediate
   inner tuple is inserted.  For this to fix the problem, the new inner
   tuple <emphasis>must</emphasis> divide the set of leaf values into more than one
   node group.  If the operator class's <function>picksplit</function> function
   fails to do that, the <acronym>SP-GiST</acronym> core resorts to
   extraordinary