MOVE strangeness - Mailing list pgsql-hackers

From Jeroen T. Vermeulen
Subject MOVE strangeness
Date
Msg-id 20021226014430.GP1393@localhost
Whole thread Raw
Responses Re: MOVE strangeness
List pgsql-hackers
Here's something that's been bothering me for a while...  Perhaps this
is correct behaviour, but I can't quite see how.  This does not happen
if I replace the FETCHes by MOVEs.

Here's the reference case:

jtv=> begin;
BEGIN
jtv=> declare c cursor for select * from events;
DECLARE CURSOR
jtv=> fetch 3 in c;year |      event       
------+------------------2010 | A Space Oddyssey2010 | Oddyssey Two2038 | time_t overflow
(3 rows)

jtv=> move -3 in c;
MOVE 2
jtv=> fetch 3 in c;year |      event       
------+------------------2010 | A Space Oddyssey2010 | Oddyssey Two2038 | time_t overflow
(3 rows)

jtv=> end;
COMMIT


Okay, since that "move -3" claims to have moved only 2 rows backwards, I
tried the same but moving backwards by only 2 rows.  This gives me the
same response for the MOVE, but my cursor evidently doesn't end up in
the same place:


jtv=> begin;
BEGIN
jtv=> declare c cursor for select * from events;
DECLARE CURSOR
jtv=> fetch 3 in c;year |      event       
------+------------------2010 | A Space Oddyssey2010 | Oddyssey Two2038 | time_t overflow
(3 rows)

jtv=> move -2 in c;
MOVE 2
jtv=> fetch 3 in c;year |      event      
------+-----------------2010 | Oddyssey Two2038 | time_t overflow1971 | jtv
(3 rows)

jtv=> end;
COMMIT


This makes it a bit hard for me to figure out just how far I moved my
cursor backwards!  Moving by BACKWARD ALL will give me the same result
as moving by -3.

Is this behaviour intentional?  If not, can it be fixed?


Jeroen




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: why we need both the collector & buffer process
Next
From: "William.Jiang"
Date:
Subject: Re: why we need both the collector & buffer process