Re: Cursors and backwards scans and SCROLL

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/