Re: [HACKERS] Single row fetch from backend

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Theo Kramer <theo(at)flame(dot)co(dot)za>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Single row fetch from backend
Date: 1999-08-13 14:41:41
Message-ID: 4375.934555301@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Theo Kramer <theo(at)flame(dot)co(dot)za> writes:
> Does postgres support the notion of single row fetch without having to use
> cursors with libpq.

Not unless you can precalculate the number of rows you want and use
LIMIT. I recommend a cursor ;-).

There has been some talk of modifying libpq so that rows could be handed
back to the application a few at a time, rather than accumulating the
whole result before PQgetResult lets you have any of it. That wouldn't
allow you to abort the SELECT early, mind you, but when you're dealing
with a really big result it would avoid waste of memory space inside the
client app. I'm not sure if that would address your problem or not.

If you really want the ability to stop the fetch from the backend at
any random point, a cursor is the only way to do it. I suppose libpq
might try to offer some syntactic sugar that would make a cursor
slightly easier to use, but it'd still be a cursor as far as the backend
and the FE/BE protocol were concerned. ecpg is probably a better answer
if you want syntactic sugar...

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Evan Simpson 1999-08-13 14:57:35 PROPOSAL: Statement for one-sided joins
Previous Message Tom Lane 1999-08-13 14:33:49 Re: [HACKERS] Index scan?