corresponding to the quadrants around this
  central point.
 </para>

 <para>
  Some tree algorithms require knowledge of level (or depth) of the current
  tuple, so the <acronym>SP-GiST</acronym> core provides the possibility for
  operator classes to manage level counting while descending the tree.
  There is also support for incrementally reconstructing the represented
  value when that is needed, and for passing down additional data (called
  <firstterm>traverse values</firstterm>) during a tree descent.
 </para>

 <note>
  <para>
   The <acronym>SP-GiST</acronym> core code takes care of null entries.
   Although <acronym>SP-GiST</acronym> indexes do store entries for nulls
   in indexed columns, this is hidden from the index operator class code:
   no null index entries or search conditions will ever be passed to the
   operator class methods.  (It is assumed that <acronym>SP-GiST</acronym>
   operators are strict and so cannot succeed for null values.)  Null values
   are therefore not discussed further here.
  </para>
 </note>

 <para>
  There are five user-defined methods that an index operator class for
  <acronym>SP-GiST</acronym> must provide, and two are optional.  All five
  mandatory methods follow the convention of accepting two <type>internal</type>
  arguments, the first of which is a pointer to a C struct containing input
  values for the support method, while the second argument is a pointer to a
  C struct where output values must be placed.  Four of the mandatory methods just
  return <type>void</type>, since all their results appear in the output struct; but
  <function>leaf_consistent</function> returns a <type>boolean</type> result.
  The methods must not modify any fields of their input structs.  In all
  cases, the output struct is initialized to zeroes before calling the
  user-defined method.  The optional sixth method <function>compress</function>
  accepts a <type>datum</type> to be indexed as the only argument and returns a value suitable
  for physical storage in a leaf tuple.  The optional seventh method
  <function>options</function> accepts an <type>internal</type> pointer to a C struct, where
  opclass-specific parameters should be placed, and returns <type>void</type>.
 </para>

 <para>
  The five mandatory user-defined methods are:
 </para>

 <variablelist>
    <varlistentry>
     <term><function>config</function></term>
     <listitem>
      <para>
       Returns static information about the index implementation, including
       the data type OIDs of the prefix and node label data types.
      </para>
     <para>
      The <acronym>SQL</acronym> declaration of the function must look like this:
<programlisting>
CREATE FUNCTION my_config(internal, internal) RETURNS void ...
</programlisting>
      The first argument is a pointer to a <structname>spgConfigIn</structname>
      C struct, containing input data for the function.
      The second argument is a pointer to a <structname>spgConfigOut</structname>
      C struct, which the function must fill with result data.
<programlisting>
typedef struct spgConfigIn
{
    Oid         attType;        /* Data type to be indexed */
} spgConfigIn;

typedef struct spgConfigOut
{
    Oid         prefixType;     /* Data type of inner-tuple prefixes */
    Oid         labelType;      /* Data type of inner-tuple node labels */
    Oid         leafType;       /* Data type of leaf-tuple values */
    bool        canReturnData;  /* Opclass can reconstruct original data */
    bool        longValuesOK;   /* Opclass can cope with values &gt; 1 page */
} spgConfigOut;
</programlisting>

      <structfield>attType</structfield> is passed in order to support polymorphic
      index operator classes; for ordinary fixed-data-type operator classes, it
      will always have the same value and so can be ignored.
     </para>

     <para>
      For operator classes that do not use prefixes,
      <structfield>prefixType</structfield> can be set to <literal>VOIDOID</literal>.