Re: I cant find it or I'm just lazy ? - Mailing list pgsql-hackers

I just tested the MOVE -5 in a simple case, and it worked:
test=> begin;BEGINtest=> declare xx cursor for select * from pg_class;DECLARE CURSORtest=> move 99999999 from xx;MOVE
157test=>move -5 from xx;MOVE 5test=> 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 pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073