libpq cursor support?
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support. I see it's been discussed in the
past ( e.g.
http://archives.postgresql.org/pgsql-interfaces/2000-09/msg00082.php ).
We have occasional reports of libpq apps blowing up on huge resultsets,
so ISTM this would be a good thing to have on the list.
I see this item under libpq:
. Allow statement results to be automatically batched to the client
but I'm not sure that would be as useful.
Thoughts?
cheers
andrew
On Wed, Mar 21, 2007 at 05:32:21PM -0400, Andrew Dunstan wrote:
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support. I see it's been discussed in the
past ( e.g.
http://archives.postgresql.org/pgsql-interfaces/2000-09/msg00082.php ).
We have occasional reports of libpq apps blowing up on huge resultsets,
so ISTM this would be a good thing to have on the list.
There are a few issues here. Right now, if you code your client
correctly, you can retreive partial resultsets before the query has
finished executing (sort of streaming). However, it is a bit clumsy.
If you get libpq to wrap each query with a DECLARE CURSOR, you'd have
to teach it what queries can and can't have it. It would be nicer to do
it at the protocol level, but I don't know if that's supported.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Andrew Dunstan <andrew@dunslane.net> writes:
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support.
I doubt that "cursor support" is what you want, but rather access to the
partial-fetch capability of extended query protocol. But that's an
implementation detail. The real question here is what would a sane
libpq API look like for partial result sets? AFAIR no one has put
forward a specific proposal.
regards, tom lane