From: Scott Lamb <slamb@slamb.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Incremental results from libpq
Date: Wed, 9 Nov 2005 14:09:09 -0800
Message-ID: <84C7635D-EAF2-40CF-A71C-976077D5465A@slamb.org> (raw)
In-Reply-To: <19391.1131571328@sss.pgh.pa.us>
References: <4D426B54-E08F-4DE9-9776-D46610CA4968@slamb.org>
<19391.1131571328@sss.pgh.pa.us>
On Nov 9, 2005, at 1:22 PM, Tom Lane wrote:
> Scott Lamb <slamb@slamb.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.)
Regards,
Scott
--
Scott Lamb <http://www.slamb.org/;
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: slamb@slamb.org, tgl@sss.pgh.pa.us
Subject: Re: Incremental results from libpq
In-Reply-To: <84C7635D-EAF2-40CF-A71C-976077D5465A@slamb.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox