Tom Lane wrote:
>
> However, this is going to create backwards-compatibility issues.
> We have a few options for what to do:
>
> 1. Enforce the SQL spec requirement: error out if backwards fetch is
> done when SCROLL wasn't given. But this will surely break a lot
> of existing applications that work perfectly well.
>
> 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.
>
> 3. Create a runtime parameter (GUC variable) which when set causes us
> to assume SCROLL is present even if it's not stated. Setting this
> to TRUE would allow existing applications to work without modification;
> when it's FALSE, we'd enforce the spec behavior. The trouble with this
> is the TRUE setting would likely cause materialization costs to be paid
> in very many situations where the client has no intention of fetching
> backwards.
The change seem worth neither #1 nor #3.
regards,
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/
