other two choices, since it requires
       scanning essentially the entire index, but it may be necessary to
       implement corner cases correctly.  An operator that needs this mode
       in most cases is probably not a good candidate for a GIN operator
       class.)
       The symbols to use for setting this mode are defined in
       <filename>access/gin.h</filename>.
      </para>

      <para>
       <literal>pmatch</literal> is an output argument for use when partial match
       is supported.  To use it, <function>extractQuery</function> must allocate
       an array of <literal>*nkeys</literal> <type>bool</type>s and store its address at
       <literal>*pmatch</literal>.  Each element of the array should be set to true
       if the corresponding key requires partial match, false if not.
       If <literal>*pmatch</literal> is set to <symbol>NULL</symbol> then GIN assumes partial match
       is not required.  The variable is initialized to <symbol>NULL</symbol> before call,
       so this argument can simply be ignored by operator classes that do
       not support partial match.
      </para>

      <para>
       <literal>extra_data</literal> is an output argument that allows
       <function>extractQuery</function> to pass additional data to the
       <function>consistent</function> and <function>comparePartial</function> methods.
       To use it, <function>extractQuery</function> must allocate
       an array of <literal>*nkeys</literal> pointers and store its address at
       <literal>*extra_data</literal>, then store whatever it wants to into the
       individual pointers.  The variable is initialized to <symbol>NULL</symbol> before
       call, so this argument can simply be ignored by operator classes that
       do not require extra data.  If <literal>*extra_data</literal> is set, the
       whole array is passed to the <function>consistent</function> method, and
       the appropriate element to the <function>comparePartial</function> method.
      </para>

     </listitem>
    </varlistentry>
  </variablelist>

  An operator class must also provide a function to check if an indexed item
  matches the query. It comes in two flavors, a Boolean <function>consistent</function>
  function, and a ternary <function>triConsistent</function> function.
  <function>triConsistent</function> covers the functionality of both, so providing
  <function>triConsistent</function> alone is sufficient. However, if the Boolean
  variant is significantly cheaper to calculate, it can be advantageous to
  provide both.  If only the Boolean variant is provided, some optimizations
  that depend on refuting index items before fetching all the keys are
  disabled.

  <variablelist>
    <varlistentry>
     <term><function>bool consistent(bool check[], StrategyNumber n, Datum query,
        int32 nkeys, Pointer extra_data[], bool *recheck,
        Datum queryKeys[], bool nullFlags[])</function></term>
     <listitem>
      <para>
       Returns true if an indexed item satisfies the query operator with
       strategy number <literal>n</literal> (or might satisfy it, if the recheck
       indication is returned).  This function does not have direct access
       to the indexed item's value, since <acronym>GIN</acronym> does not
       store items explicitly.  Rather, what is available is knowledge
       about which key values extracted from the query appear in a given
       indexed item.  The <literal>check</literal> array has length
       <literal>nkeys</literal>, which is the same as the number of keys previously
       returned by <function>extractQuery</function> for this <literal>query</literal> datum.
       Each element of the
       <literal>check</literal> array is true if the indexed item contains the
       corresponding query key, i.e., if (check[i] == true) the i-th key of the
       <function>extractQuery</function> result array is present in the indexed item.
       The original <literal>query</literal> datum is