Re: [HACKERS] Single row fetch from backend - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Single row fetch from backend
Date
Msg-id 4375.934555301@sss.pgh.pa.us
Whole thread Raw
In response to Single row fetch from backend  (Theo Kramer <theo@flame.co.za>)
List pgsql-hackers
Theo Kramer <theo@flame.co.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Index scan?
Next
From: "Evan Simpson"
Date:
Subject: PROPOSAL: Statement for one-sided joins