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 по дате отправления: