Add note clarifying that indexes that support ordered scans had better

allow clauseless scans.

diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml
index ef1e37a82605644e08f538233ff71cabe1da6781..9a84509f749aba91bada4777fec2df50d63b89e0 100644 (file)
--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.3 2005/03/27 23:52:51 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.4 2005/04/20 22:19:58 tgl Exp $
 -->
 
 <chapter id="indexam">
@@ -109,7 +109,8 @@ $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.3 2005/03/27 23:52:51 tgl Exp $
    such a scan should include null rows.  In practice this means that
    indexes that support ordered scans (have <structfield>amorderstrategy</>
    nonzero) must index nulls, since the planner might decide to use such a
-   scan as a substitute for sorting.  Another restriction is that an index
+   scan as a substitute for sorting.  Such indexes must also be willing to
+   run a scan with no scan keys at all.  Another restriction is that an index
    access method that supports multiple index columns <emphasis>must</>
    support indexing null values in columns after the first, because the planner
    will assume the index can be used for queries on just the first