Pointer extra_data)</function></term>
     <listitem>
      <para>
       Compare a partial-match query key to an index key.  Returns an integer
       whose sign indicates the result: less than zero means the index key
       does not match the query, but the index scan should continue; zero
       means that the index key does match the query; greater than zero
       indicates that the index scan should stop because no more matches
       are possible.  The strategy number <literal>n</literal> of the operator
       that generated the partial match query is provided, in case its
       semantics are needed to determine when to end the scan.  Also,
       <literal>extra_data</literal> is the corresponding element of the extra-data
       array made by <function>extractQuery</function>, or <symbol>NULL</symbol> if none.
       Null keys are never passed to this function.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><function>void options(local_relopts *relopts)</function></term>
     <listitem>
      <para>
       Defines a set of user-visible parameters that control operator class
       behavior.
      </para>

      <para>
       The <function>options</function> 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 both key extraction of indexed values and representation of the
       key in <acronym>GIN</acronym> are flexible, they may depend on
       user-specified parameters.
      </para>
     </listitem>
    </varlistentry>
  </variablelist>
 </para>

 <para>
  To support <quote>partial match</quote> queries, an operator class must
  provide the <function>comparePartial</function> method, and its
  <function>extractQuery</function> method must set the <literal>pmatch</literal>
  parameter when a partial-match query is encountered.  See
  <xref linkend="gin-partial-match"/> for details.
 </para>

 <para>
  The actual data types of the various <literal>Datum</literal> values mentioned
  above vary depending on the operator class.  The item values passed to
  <function>extractValue</function> are always of the operator class's input type, and
  all key values must be of the class's <literal>STORAGE</literal> type.  The type of
  the <literal>query</literal> argument passed to <function>extractQuery</function>,
  <function>consistent</function> and <function>triConsistent</function> is whatever is the
  right-hand input type of the class member operator identified by the
  strategy number.  This need not be the same as the indexed type, so long as
  key values of the correct type can be extracted from it.  However, it is
  recommended that the SQL declarations of these three support functions use
  the opclass's indexed data type for the <literal>query</literal> argument, even
  though the actual type might be something else depending on the operator.
 </para>

</sect2>

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

 <para>
  Internally, a <acronym>GIN</acronym> index contains a B-tree index
  constructed over keys, where each key is an element of one or more indexed
  items (a member of an array, for example) and where each tuple in a leaf
  page contains either a pointer to a B-tree of heap pointers (a
  <quote>posting tree</quote>), or a simple list of heap pointers (a <quote>posting
  list</quote>) when the list is small enough to fit into a single index tuple along
  with the key value.  <xref linkend="gin-internals-figure"/> illustrates
  these components of a GIN index.
 </para>

 <para>
  As of <productname>PostgreSQL</productname> 9.1, null key values can be
  included in the index.  Also, placeholder nulls are included in