Skip site navigation (1) Skip section navigation (2)

Re: scrollable cursor support without MOVE statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-patches(at)postgresql(dot)org, magnus(at)hagander(dot)net, bruce(at)momjian(dot)us
Subject: Re: scrollable cursor support without MOVE statement
Date: 2007-04-16 22:56:58
Message-ID: 11760.1176764218@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Mon, 2007-04-16 at 18:18 -0400, Tom Lane wrote:
>> There is no change in the default behavior.

> Previously:
> - PL/pgSQL cursors were non-scrollable
> - DECLARE CURSOR cursors were not non-scrollable by default

No, they weren't "non-scrollable", they were the same as the default
case for DECLARE CURSOR.  You just couldn't tell (from within plpgsql
anyway) for lack of any form of FETCH that would exercise backward
motion.

The actual code behavior is, and has been for a long time,

SCROLL -> if plan doesn't handle backwards scan, stick a Materialize
node atop it so it can.

NO SCROLL -> do nothing to plan.  In pquery.c, throw error if an attempt
is made to fetch backwards.

default -> if plan doesn't handle backwards scan, use NO SCROLL behavior.
If it does, silently allow scrolling.

The previous state of affairs was that plpgsql had no way to specify
SCROLL or NO SCROLL and so always got the default behavior.  Now it
does, but the default behavior is still the same.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2007-04-16 23:01:04
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
Previous:From: Simon RiggsDate: 2007-04-16 22:42:21
Subject: Re: scrollable cursor support without MOVE statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group