Thanx for the response, Tom, which was, unfortunately, pretty close to what I feared. I'm
glad to hear that a fix is pending but I am concerned about the performance issue. Some of the
queries that my form will be browsing are in the tens of thousands of results. This is actually the
reason why I use cursors so I can just fetch one screen full of results but bounce back and forth in
the result set to get where I want. Saving copies of what actually gets fetched will be fine, but
saving copies of anything that I actually scroll by would quickly be prohibitive Presently I guess I
could do a fetch all and get the same result. A much preferable solution would be the ability to
determine absolute position of the query and even pay the performance cost of re-querying at some
points. I imagine that this it outside the SQL standard but I'm willing to take that penalty to get
around a complex query limitation. I haven't tried it yet but I presume a view built from a complex
query will give me the same problem?
thanx & later,
Ben Scherrey
4/28/2003 11:51:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Benjamin Scherrey <scherrey@proteus-tech.com> writes:
>> I've been developing a web-based selection browser using cursors and
>> discovered a very frustrating little feature as I try to MOVE
>> FORWARD/BACKWARD through my selection.
>
>You can't run a nontrivial query plan (anything more than a seqscan or
>indexscan) backwards with any reliability. There are fixes for this in
>CVS tip, but not in any released version :-(. It should also be noted
>that the fix consists of saving-aside copies of all rows emitted by the
>underlying query, so if you are talking about a large result set you
>might not like the performance...
>
> regards, tom lane
