Re: Cursors and backwards scans and SCROLL

>> 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