I said:
> Yeah, backwards scan is not implemented for quite a large number of plan
> node types :-(. I am not sure that it is practical to fix them all.
> I have been toying with the notion of making cursors on complex plans
> safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
> the top plan node isn't one that can handle backwards scan.
I forgot to mention plan B: make use of ReScan. This could work like
so:
1. Cursor keeps track of row number (number of rows it's fetched).
2. To scan backwards when top plan type doesn't handle it, rewind all
the way with ReScan, then move forward the appropriate number of rows.
This would avoid any added overhead in the case where a backwards move
is never requested, and it also would support MOVE BACKWARD ALL quite
efficiently (much more so than now). On the other hand, it'd really
suck if the user asks for backwards scan from a point far into the
output.
Perhaps we could do something with a hybrid technique: don't materialize
the cursor output unless user actually asks for backwards scan. If he
does, then create a tuplestore and put the data into it (rescanning the
query output to do so), and finally supply the tuples from the tuplestore.
regards, tom lane
