Skip site navigation (1) Skip section navigation (2)

Re: Incremental results from libpq

From: Scott Lamb <slamb(at)slamb(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Incremental results from libpq
Date: 2005-11-09 22:09:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Nov 9, 2005, at 1:22 PM, Tom Lane wrote:
> Scott Lamb <slamb(at)slamb(dot)org> writes:
>> Is there a better way?
> Not at the moment.  It's been requested before though, so if you  
> want to
> develop a patch for libpq, have at it.
> The main reason why libpq does what it does is that this way we do not
> have to expose in the API the notion of a command that fails part way
> through.  If you support partial result fetching then you'll have to
> deal with the idea that a SELECT could fail after you've already
> returned some rows to the client.  I am not sure that this is a huge
> deal, but it definitely uglifies the API a bit.  It would be a good
> idea to think through exactly what clients will need to do to cope  
> with
> that fact before you start designing the API extension.

Cool. I think I'll get my own interface hashed out in my kludgey way,  
then look at the broader need if it's a success.

My first idea, though, is to add a callback interface - "got the  
RowDescription", "got a DataRow" - and make the storage of stuff  
tuples in PGresult optional. (Maybe pqAddTuple would just be the  
default callback.)


Scott Lamb <>

In response to


pgsql-interfaces by date

Next:From: Frank van VugtDate: 2005-11-10 09:11:45
Subject: Re: Incremental results from libpq
Previous:From: Tom LaneDate: 2005-11-09 21:22:08
Subject: Re: Incremental results from libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group