1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-25 01:02:05 +03:00

Add a new column to pg_am to specify whether an index AM supports backward

scanning; GiST and GIN do not, and it seems like too much trouble to make
them do so.  By teaching ExecSupportsBackwardScan() about this restriction,
we ensure that the planner will protect a scroll cursor from the problem
by adding a Materialize node.

In passing, fix another longstanding bug in the same area: backwards scan of
a plan with set-returning functions in the targetlist did not work either,
since the TupFromTlist expansion code pays no attention to direction (and
has no way to run a SRF backwards anyway).  Again the fix is to make
ExecSupportsBackwardScan check this restriction.

Also adjust the index AM API specification to note that mark/restore support
is unnecessary if the AM can't produce ordered output.
This commit is contained in:
Tom Lane
2008-10-17 22:10:30 +00:00
parent 2a64931c4b
commit e4fb8ff06a
5 changed files with 119 additions and 42 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.178 2008/10/06 13:59:37 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.179 2008/10/17 22:10:29 tgl Exp $ -->
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
-->
@ -401,6 +401,13 @@
<entry>Does the access method support ordered scans?</entry>
</row>
<row>
<entry><structfield>amcanbackward</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does the access method support backward scanning?</entry>
</row>
<row>
<entry><structfield>amcanunique</structfield></entry>
<entry><type>bool</type></entry>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.27 2008/08/14 18:47:58 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.28 2008/10/17 22:10:29 tgl Exp $ -->
<chapter id="indexam">
<title>Index Access Method Interface Definition</title>
@ -474,15 +474,20 @@ amrestrpos (IndexScanDesc scan);
normally would. (This will only occur for access
methods that advertise they support ordered scans.) After the
first call, <function>amgettuple</> must be prepared to advance the scan in
either direction from the most recently returned entry.
either direction from the most recently returned entry. (But if
<structname>pg_am</>.<structfield>amcanbackward</> is false, all subsequent
calls will have the same direction as the first one.)
</para>
<para>
The access method must support <quote>marking</> 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</> call overrides the previously
marked position.
Access methods that support ordered scans must support <quote>marking</> 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</> call overrides the
previously marked position. An access method that does not support
ordered scans should still provide mark and restore functions in
<structname>pg_am</>, but it is sufficient to have them throw errors if
called.
</para>
<para>