Re: Practical impediment to supporting multiple SSL libraries

* Martijn van Oosterhout (kleptog(at)svana(dot)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