Re: Incorrect cursor behaviour with gist index

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> Seems like a lotta work for a partial solution :-(. Probably the path
>> of least resistance is to teach the planner that only some index AMs can
>> do backwards scan. That would result in a Materialize buffer getting
>> placed in front of the query if the user demanded scroll capability,
>> but it would cost nothing in the more typical case where backwards scan
>> isn't needed.

> Probably, it will be a better solution. In this case GiST code could be
> simplified - remove support of backward scan (in any case not fully workable)

Okay. I'll go fix the core code, and you can take out whatever you want
in GiST/GIN.

BTW, I think that the support for ammarkpos/amrestrpos in these two AMs
is pretty much useless code as well. We only use mark/restore in merge
joins, and so it only needs to be supported by plan nodes that can
deliver sorted output, which GiST/GIN indexscans can't. Furthermore,
even if we had another use for the facility, it'd be pretty questionable
to use it when the AM can't guarantee to return the same sequence of
tuples after backing up. So I think it would be sufficient to have
gistmarkpos et al throw error if called.

regards, tom lane