Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]