>> 2. Error out only if a backwards fetch is actually attempted on a plan
>> tree that can't handle it (which could only happen if SCROLL wasn't
>> given).  This is efficient and flexible, but it exposes implementation
>> details to the user, in that whether an error occurs will depend on
>> which plan the system happens to choose.  There are cases where
>> identical cursor definitions might allow or not allow backwards fetch
>> depending on the planner's choices. Notice though that errors could
>> occur only in cases that would silently fail in the present code; so
>> existing applications that work reliably would not see such errors.

> 2. like your #2,

I vote #2 also.

> but just give a warning and then run the underlying
> query _again_, this toime with materialize on top and also do a Move to
> reposition the cursor. This will probably not work correctly for all
> tranasaction isolation levels though but it will penalize only these
> cases that absolutely need it. The penalty will of course be 
> heavier ;(

rescan can only work in serializable isolation, no?
In committed read isolation you will see different (just comitted) rows
from a rescan.

Andreas

Mon, 10 Mar 2003 10:29:19 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Cursors and backwards scans and SCROLL
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> but just give a warning and then run the underlying
>> query _again_, this toime with materialize on top and also do a Move to
>> reposition the cursor. This will probably not work correctly for all
>> tranasaction isolation levels though but it will penalize only these
>> cases that absolutely need it. The penalty will of course be 
>> heavier ;(

> rescan can only work in serializable isolation, no?

I had thought about this and concluded it was not worth the trouble.
It could be made to work if we copy the snapshot data from old plan to
new, but realistically there's no value in it.  Existing applications
that are successfully using backwards-fetch are using queries that don't
need materialization; therefore there's no compatibility gain from
adding this extra code.

			regards, tom lane

Mon, 10 Mar 2003 09:40:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Cursors and backwards scans and SCROLL 