<literal>InvalidOid</literal>.
   The <type>List</type> arguments are lists
   of <structname>OpFamilyMember</structname> structs, as defined
   in <filename>amapi.h</filename>.

   Tests done by this function will typically be a subset of those
   performed by <function>amvalidate</function>,
   since <function>amadjustmembers</function> cannot assume that it is
   seeing a complete set of members.  For example, it would be reasonable
   to check the signature of a support function, but not to check whether
   all required support functions are provided.  Any problems can be
   reported by throwing an error.

   The dependency-related fields of
   the <structname>OpFamilyMember</structname> structs are initialized by
   the core code to create hard dependencies on the opclass if this
   is <command>CREATE OPERATOR CLASS</command>, or soft dependencies on the
   opfamily if this is <command>ALTER OPERATOR FAMILY ADD</command>.
   <function>amadjustmembers</function> can adjust these fields if some other
   behavior is more appropriate.  For example, GIN, GiST, and SP-GiST
   always set operator members to have soft dependencies on the opfamily,
   since the connection between an operator and an opclass is relatively
   weak in these index types; so it is reasonable to allow operator members
   to be added and removed freely.  Optional support functions are typically
   also given soft dependencies, so that they can be removed if necessary.
  </para>


  <para>
   The purpose of an index, of course, is to support scans for tuples matching
   an indexable <literal>WHERE</literal> condition, often called a
   <firstterm>qualifier</firstterm> or <firstterm>scan key</firstterm>.  The semantics of
   index scanning are described more fully in <xref linkend="index-scanning"/>,
   below.  An index access method can support <quote>plain</quote> index scans,
   <quote>bitmap</quote> index scans, or both.  The scan-related functions that an
   index access method must or may provide are:
  </para>

  <para>
<programlisting>
IndexScanDesc
ambeginscan (Relation indexRelation,
             int nkeys,
             int norderbys);
</programlisting>
   Prepare for an index scan.  The <literal>nkeys</literal> and <literal>norderbys</literal>
   parameters indicate the number of quals and ordering operators that will be
   used in the scan; these may be useful for space allocation purposes.
   Note that the actual values of the scan keys aren't provided yet.
   The result must be a palloc'd struct.
   For implementation reasons the index access method
   <emphasis>must</emphasis> create this struct by calling
   <function>RelationGetIndexScan()</function>.  In most cases
   <function>ambeginscan</function> does little beyond making that call and perhaps
   acquiring locks;
   the interesting parts of index-scan startup are in <function>amrescan</function>.
  </para>

  <para>
<programlisting>
void
amrescan (IndexScanDesc scan,
          ScanKey keys,
          int nkeys,
          ScanKey orderbys,
          int norderbys);
</programlisting>
   Start or restart an index scan, possibly with new scan keys.  (To restart
   using previously-passed keys, NULL is passed for <literal>keys</literal> and/or
   <literal>orderbys</literal>.)  Note that it is not allowed for
   the number of keys or order-by operators to be larger than
   what was passed to <function>ambeginscan</function>.  In practice the restart
   feature is used when a new outer tuple is selected by a nested-loop join
   and so a new key comparison value is needed, but the scan key structure
   remains the same.
  </para>

  <para>
<programlisting>
bool
amgettuple (IndexScanDesc scan,
            ScanDirection direction);
</programlisting>
   Fetch the next tuple in the given scan, moving in the given
   direction (forward or backward in the index).  Returns true if a tuple was
   obtained, false if no matching tuples remain.  In the true case the tuple
   TID is stored into the <literal>scan</literal>