Message-ID: <3E6C58E1.D7642B4@tpf.co.jp>
Date: Mon, 10 Mar 2003 18:20:33 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: Cursors and backwards scans and SCROLL
References: <21621.1047242111@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

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 Inoue
	http://www.geocities.jp/inocchichichi/psqlodbc/