Re: Incremental results from libpq
От | Scott Lamb |
---|---|
Тема | Re: Incremental results from libpq |
Дата | |
Msg-id | 84C7635D-EAF2-40CF-A71C-976077D5465A@slamb.org обсуждение исходный текст |
Ответ на | Re: Incremental results from libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Incremental results from libpq
Re: Incremental results from libpq Re: Incremental results from libpq |
Список | pgsql-interfaces |
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/>
В списке pgsql-interfaces по дате отправления: