Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What I think you are seeing are that certain cursors can't go backwards.
Lots of the more complex plan node types don't correctly implement
backwards fetch. I've looked briefly at fixing that, but it looks like
it'd be a major pain in the rear for some cases, such as Agg nodes.
A stopgap I've been considering is to add code that knows which plan node
types can go backwards. Then, if the cursor logic needs to go backwards
on a plan type that doesn't support it, it could instead rewind to start
(all plan types seem to support Rescan) and step forwards the correct
number of rows. This could be horribly inefficient but at least it
would work.
A less inefficient solution would be to stick a Materialize node atop
the plan, but the trouble is that would be a huge penalty for the common
cases where no backwards scan is actually ever done. Maybe we could
have the cursor logic insert the Materialize node on-the-fly when the
first backwards motion command is received. Also, we could implement
the SQL keyword "SCROLL" and say that you have to specify SCROLL if you
don't want this extra work to occur (with SCROLL, we could insert
Materialize if needed before starting).
regards, tom lane
