number of rows in a cursor

[Christoffer Gurell]

After declaring a cursor. Is there any way you can check the number of rows
that cursor contains ??

/ Christoffer Gurell
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Bruce Momjian]

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
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Bruce Momjian <pg***@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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[scott.marlowe]

On Tue, 10 Feb 2004, Tom Lane wrote:

Bruce Momjian <pg***@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?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly