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