* Martijn van Oosterhout (kleptog@svana.org) wrote: > Well, I quickly scanned the code in CVS to see what I could find out.
Wow, that was quick. :)
> So in fact what you really want is libpq as a protocol decoder but want
> to manage your resultset yourself. And you want to be able to let users
> handle incoming data as it comes rather than waiting for the whole set.
The data-as-it-comes bit could be done w/ a Postgres cursor, couldn't
it? But then you have to read through all the data using PQgetResult,
which isn't much fun.
> I don't think the zero-copy is relevent, the code is not written in a
> way that suggests speed was an issue. Rather I think the way you want
> to use the resultset is the issue. You can't use the memory in the
> PGresult because then'd you need to track which tuples were allocated
> by you and which we allocated by libpq. The resulting copying is
> needless, along with the fact that you double your memory usage.
The double memory usage definitely sucks but I really think speed would
also be greatly improved by removing the double copying and all the
function calls dealing with PQgetResult, etc...
> In fact, can think that a number of other projects would like an
> alternative. For example, a Perl module would want to load the strings
> directly into blessed perl strings rather than keep a copy of the
> resultset around. I think this would be a worthwhile addition to the
> libpq interface.
Me too. :)
> I'll see if I can come up with a proposal (whether it'll get
> implemented is another issue entirely).
I'd be interested in trying to help with this too..
Thanks,
Stephen
signature.asc
Description: Digital signature
