Postgres Pro
Downloads
Home   >   mailing lists

Thread: number of rows in a cursor

number of rows in a cursor

From
Christoffer Gurell
Date:
After declaring a cursor. Is there any way you can check the number of rows
that cursor contains ??

 / Christoffer Gurell

Re: number of rows in a cursor

From
Bruce Momjian
Date:
Christoffer Gurell wrote:
> After declaring a cursor. Is there any way you can check the number of rows
> that cursor contains ??

    test=> BEGIN;
    BEGIN
    test=> DECLARE xxx CURSOR FOR SELECT * FROM pg_class;
    DECLARE CURSOR
    test=> MOVE ALL IN xxx;
    MOVE 184

Yes, you can MOVE ALL in the cursor and look at the return status, in
this case 184 rows.

--
  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, Pennsylvania 19073

Re: number of rows in a cursor

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Christoffer Gurell wrote:
>> After declaring a cursor. Is there any way you can check the number of rows
>> that cursor contains ??

> Yes, you can MOVE ALL in the cursor and look at the return status,

Note however that this is *not* a cheap operation.  You might as well
fetch the data, because it's going to cost nearly as much as FETCH.

(Worse, in pre-7.4 versions, MOVE BACKWARDS ALL is also nearly as
expensive as FETCH, so that getting the number of rows and then fetching
the data will cost you close to 3x the runtime of the FETCH alone.)

            regards, tom lane

Re: number of rows in a cursor

From
"scott.marlowe"
Date:
On Tue, 10 Feb 2004, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Christoffer Gurell wrote:
> >> After declaring a cursor. Is there any way you can check the number of rows
> >> that cursor contains ??
>
> > Yes, you can MOVE ALL in the cursor and look at the return status,
>
> Note however that this is *not* a cheap operation.  You might as well
> fetch the data, because it's going to cost nearly as much as FETCH.
>
> (Worse, in pre-7.4 versions, MOVE BACKWARDS ALL is also nearly as
> expensive as FETCH, so that getting the number of rows and then fetching
> the data will cost you close to 3x the runtime of the FETCH alone.)

At that point wouldn't a select count(*) from table where...

be cheaper?