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:
@ -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>
|
||||
|
@ -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>
|
||||
|
Reference in New Issue
Block a user