Re: Practical impediment to supporting multiple SSL libraries

On Thu, Apr 13, 2006 at 12:48:06PM +0100, Dave Page wrote:
> Anyhoo, as I've said, that approach has now been abandoned anyway in
> favour of Hiroshi's, so it's him you'd need to convince to change. The
> rest of us have only just started re-learning the code.

Well, I quickly scanned the code in CVS to see what I could find out.
There are a few features the psqlodbc tuplereader has that libpq
doesn't.

1. It reads tuples as you go through the data. The resultset has a
cursor, it only processes the data as you request it.

2. It reads directly from the socket directly into a per-tuple
malloc()ed field.

3. It extracts per-row tids directly into a seperate array.

4. The resulting resultset can be updated and modified as well as
appended to. This requires freeing and adding rows. And committing the
result. This is probably your updatable cursors.

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.

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.

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.

I'll see if I can come up with a proposal (whether it'll get
implemented is another issue entirely).

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.