reading
   this chapter.
  </para>

  <para>
   An individual index is defined by a
   <link linkend="catalog-pg-class"><structname>pg_class</structname></link>
   entry that describes it as a physical relation, plus a
   <link linkend="catalog-pg-index"><structname>pg_index</structname></link>
   entry that shows the logical content of the index &mdash; that is, the set
   of index columns it has and the semantics of those columns, as captured by
   the associated operator classes.  The index columns (key values) can be
   either simple columns of the underlying table or expressions over the table
   rows.  The index access method normally has no interest in where the index
   key values come from (it is always handed precomputed key values) but it
   will be very interested in the operator class information in
   <structname>pg_index</structname>.  Both of these catalog entries can be
   accessed as part of the <structname>Relation</structname> data structure that is
   passed to all operations on the index.
  </para>

  <para>
   Some of the flag fields of <structname>IndexAmRoutine</structname> have nonobvious
   implications.  The requirements of <structfield>amcanunique</structfield>
   are discussed in <xref linkend="index-unique-checks"/>.
   The <structfield>amcanmulticol</structfield> flag asserts that the
   access method supports multi-key-column indexes, while
   <structfield>amoptionalkey</structfield> asserts that it allows scans
   where no indexable restriction clause is given for the first index column.
   When <structfield>amcanmulticol</structfield> is false,
   <structfield>amoptionalkey</structfield> essentially says whether the
   access method supports full-index scans without any restriction clause.
   Access methods that support multiple index columns <emphasis>must</emphasis>
   support scans that omit restrictions on any or all of the columns after
   the first; however they are permitted to require some restriction to
   appear for the first index column, and this is signaled by setting
   <structfield>amoptionalkey</structfield> false.
   One reason that an index <acronym>AM</acronym> might set
   <structfield>amoptionalkey</structfield> false is if it doesn't index
   null values.  Since most indexable operators are
   strict and hence cannot return true for null inputs,
   it is at first sight attractive to not store index entries for null values:
   they could never be returned by an index scan anyway.  However, this
   argument fails when an index scan has no restriction clause for a given
   index column.  In practice this means that
   indexes that have <structfield>amoptionalkey</structfield> true must
   index nulls, since the planner might decide to use such an index
   with no scan keys at all.  A related restriction is that an index
   access method that supports multiple index columns <emphasis>must</emphasis>
   support indexing null values in columns after the first, because the planner
   will assume the index can be used for queries that do not restrict
   these columns.  For example, consider an index on (a,b) and a query with
   <literal>WHERE a = 4</literal>.  The system will assume the index can be
   used to scan for rows with <literal>a = 4</literal>, which is wrong if the
   index omits rows where <literal>b</literal> is null.
   It is, however, OK to omit rows where the first indexed column is null.
   An index access method that does index nulls may also set
   <structfield>amsearchnulls</structfield>, indicating that it supports
   <literal>IS NULL</literal> and <literal>IS NOT NULL</literal> clauses as search
   conditions.
  </para>

  <para>
   The <structfield>amcaninclude</structfield> flag indicates whether the
   access method supports <quote>included</quote> columns, that is it can
   store (without processing) additional columns beyond the key column(s).
   The requirements of the preceding paragraph apply only to the key
   columns.  In particular, the combination