Subject: Re: Cursors and backwards scans and SCROLL
From: Hannu Krosing <hannu@tm.ee>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
In-Reply-To: <21621.1047242111@sss.pgh.pa.us>
References: <21621.1047242111@sss.pgh.pa.us>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1047280477.2892.11.camel@fuji.krosing.net>
Mime-Version: 1.0
Date: 10 Mar 2003 09:14:38 +0200

Tom Lane kirjutas P, 09.03.2003 kell 22:35:

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

We could start by issuing a NOTICE/WARNING as a step towards the strict
compliance and provide a GUC variable for those who are unable to cope
even with the warning.

The warning could be issued at two places - 

1. ( more annoying ) issue it at cursor creation time when a plan is
chosen that can't be fetched backwards.

2. like your #2, 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 ;(

-----------------
Hannu