aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2008-10-17 22:10:30 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2008-10-17 22:10:30 +0000
commite4fb8ff06a8aa1b4c073c46f63b7effd5885e327 (patch)
tree870a38b1b82a5d72dd4bc63ec1270593f0d33936 /src/backend/access/gist/gistget.c
parent2a64931c4bc76c5e800c3fb1eb5a18dc256899c9 (diff)
downloadpostgresql-e4fb8ff06a8aa1b4c073c46f63b7effd5885e327.tar.gz
postgresql-e4fb8ff06a8aa1b4c073c46f63b7effd5885e327.zip
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.
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions