I just tested the MOVE -5 in a simple case, and it worked:
test=> begin;
BEGIN
test=> declare xx cursor for select * from pg_class;
DECLARE CURSOR
test=> move 99999999 from xx;
MOVE 157
test=> move -5 from xx;
MOVE 5
test=> fetch 1 from xx;
relname | relnamespace | reltype | relowner | relam | relfilenode |
relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared |
relkind | relnatts | relchecks | reltriggers | relukeys | relfkeys | relrefs |
relhasoids | relhaspkey | relhasrules | relhassubclass | relacl
--------------+--------------+---------+----------+-------+-------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+---------------
pg_namespace | 11 | 16595 | 1 | 0 | 16594 |
1 | 5 | 0 | 0 | t | f | r
| 3 | 0 | 0 | 0 | 0 | 0 | t | f
| f | f | {=r/postgres}
(1 row)
What I think you are seeing are that certain cursors can't go backwards.
However, I don't know the details. Anyone?
---------------------------------------------------------------------------
Darko Prenosil wrote:
> On Thursday 06 March 2003 19:08, Bruce Momjian wrote:
> > Jeroen T. Vermeulen wrote:
> > > On Tue, Feb 25, 2003 at 02:04:50PM +0100, Christoph Haller wrote:
> > > > Anyway, you may MOVE until 0 instead of FETCH, or use the COUNT()
> > > > function on the query to learn about the number of rows to be returned.
> > >
> > > Hmm... Wouldn't the reliability of a count() depend on the isolation
> > > level?
> > >
> > > OTOH the problem with MOVE ALL is that not all cursors support backward
> > > scrolling, apparently, and there is no clear documentation (or even
> > > diagnostics!) to determine whether they do.
> >
> > 7.4 does document MOVE ALL as going to the end of the cursor.
>
> Great, Bruce is back !
> I drop the idea to use cursors for recordset buffering, and I'm using temp
> tables. MOVE ALL can solve my first problem, but It can't solve the other
> one: How to know if there is transaction in progress ? The final facts were:
>
> For cursor:
> Fast, and less memory (concerning that only query plan is stored on
> server).
> Against cursor:
> I can't determine if transaction is already in progress, so I do not
> know can I COMMIT on cursor close. (Maybe some other of my recordset
> controls started transactions before)
>
> For table:
> I do not need transaction
> Against table:
> More memory, and slower positioning in the buffer(using LIMIT and
> OFFSET)
>
> OK it is slower, but it works !
>
> I must say one more thing I noticed experimenting with cursors:
> Let's say that we have cursor with 10 rows, if we MOVE 11 rows, cursor
> become unusable, because even if we after that MOVE -5, no row can be
> fetched. I do not think that this is bug, but at last notice should be raised
> with warning that we missed the cursors size. I even find the code that is
> working with cursor, and tried to figure out how to fix this, but it is too
> much for me. Sorry !
>
> Regards !
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
