Re: [HACKERS] Single row fetch from backend

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Single row fetch from backend
Дата
Msg-id 4375.934555301@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Single row fetch from backend  (Theo Kramer <theo@flame.co.za>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Index scan?
Следующее
От: "Evan Simpson"
Дата:
Сообщение: PROPOSAL: Statement for one-sided joins