Date: Mon, 10 Mar 2003 16:32:46 +0100
From: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: Cursors and backwards scans and SCROLL
Message-ID: <20030310153245.GW98248@xs4all.nl>
Mail-Followup-To: Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
References: <21621.1047242111@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21621.1047242111@sss.pgh.pa.us>
User-Agent: Mutt/1.4i

On Sun, Mar 09, 2003 at 03:35:11PM -0500, Tom Lane wrote:
> 
> 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.  

I wouldn't worry too much about exposing implementation details at 
present--the existing situation does the same, except it pretends that
not returning data that should be there isn't an error.  Absent any
further documentation, I'd call that a bug that needs to be fixed.


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

Would it be possible to give warnings in a narrow superset of the
problematic cases, something along the lines of "I'm scrolling backwards
for you now, but there's no reason why that should work on this same query 
tomorrow"?


Jeroen