simply hand off all the <literal>WHERE</literal>
   clauses that match the index keys and operator families, without any
   semantic analysis to determine whether they are redundant or
   contradictory.  As an example, given
   <literal>WHERE x &gt; 4 AND x &gt; 14</literal> where <literal>x</literal> is a b-tree
   indexed column, it is left to the b-tree <function>amrescan</function> function
   to realize that the first scan key is redundant and can be discarded.
   The extent of preprocessing needed during <function>amrescan</function> will
   depend on the extent to which the index access method needs to reduce
   the scan keys to a <quote>normalized</quote> form.
  </para>

  <para>
   Some access methods return index entries in a well-defined order, others
   do not.  There are actually two different ways that an access method can
   support sorted output:

    <itemizedlist>
     <listitem>
      <para>
       Access methods that always return entries in the natural ordering
       of their data (such as btree) should set
       <structfield>amcanorder</structfield> to true.
       Currently, such access methods must use btree-compatible strategy
       numbers for their equality and ordering operators.
      </para>
     </listitem>
     <listitem>
      <para>
       Access methods that support ordering operators should set
       <structfield>amcanorderbyop</structfield> to true.
       This indicates that the index is capable of returning entries in
       an order satisfying <literal>ORDER BY</literal> <replaceable>index_key</replaceable>
       <replaceable>operator</replaceable> <replaceable>constant</replaceable>.  Scan modifiers
       of that form can be passed to <function>amrescan</function> as described
       previously.
      </para>
     </listitem>
    </itemizedlist>
  </para>

  <para>
   The <function>amgettuple</function> function has a <literal>direction</literal> argument,
   which can be either <literal>ForwardScanDirection</literal> (the normal case)
   or  <literal>BackwardScanDirection</literal>.  If the first call after
   <function>amrescan</function> specifies <literal>BackwardScanDirection</literal>, then the
   set of matching index entries is to be scanned back-to-front rather than in
   the normal front-to-back direction, so <function>amgettuple</function> must return
   the last matching tuple in the index, rather than the first one as it
   normally would.  (This will only occur for access
   methods that set <structfield>amcanorder</structfield> to true.)  After the
   first call, <function>amgettuple</function> must be prepared to advance the scan in
   either direction from the most recently returned entry.  (But if
   <structfield>amcanbackward</structfield> is false, all subsequent
   calls will have the same direction as the first one.)
  </para>

  <para>
   Access methods that support ordered scans must support <quote>marking</quote> a
   position in a scan and later returning to the marked position.  The same
   position might be restored multiple times.  However, only one position need
   be remembered per scan; a new <function>ammarkpos</function> call overrides the
   previously marked position.  An access method that does not support ordered
   scans need not provide <function>ammarkpos</function> and <function>amrestrpos</function>
   functions in <structname>IndexAmRoutine</structname>; set those pointers to NULL
   instead.
  </para>

  <para>
   Both the scan position and the mark position (if any) must be maintained
   consistently in the face of concurrent insertions or deletions in the
   index.  It is OK if a freshly-inserted entry is not returned by a scan that
   would have found the entry if it had existed when the scan started, or for
   the scan to return such an entry upon rescanning or backing
   up even though it had not been returned the first time through.  Similarly,
   a concurrent delete might or might not be reflected in the results of a scan.
   What