Thread: 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/ > 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