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)
It should be sufficient to specify this in pg_am, right? Or could the
opclass or indexkey details affect it?
I don't see any examples where it depends on opclass or index key, that's is a
AM property.
BTW, can GIN do backwards scan?
No, at all.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
