Re: Practical impediment to supporting multiple SSL libraries

On Thu, Apr 13, 2006 at 12:12:25PM +0100, Dave Page wrote:
> > Ok. I'm not sure what this "double copying" you're referring
> > to is,
>
> The libpq driver copies results out of the PGresult struct into the
> internal QueryResult classes. With libpq out of the loop, data can go
> straight from the wire into the QR.

Hmm, the simplest improvement I can think of is one where you
register a callback that libpq calls whenever it has received a new
tuple.

However, w.r.t. the copying, the pointers in get PGresult are in memory
belonging to that result. As long as that PGresult hangs around, you
should be able to just copy the pointers rather than the data? Or is
this unacceptable?

The only alternative I can think of is let users provide a callback
that is given the number of bytes and it returns memory to store the
data into. But that just seems unnecessarily complex, considering you
could just copy the pointers.

> There are elements of the wire protocol that libpq doesn't actually
> implement from what I recall. IIRC, they were added specifically for
> JDBC but also intended to be used by psqlODBC as well. I forget the
> details though as I wasn't so involved with the ODBC development back
> then.

Ugh, that's terrible. How do these features get tested if nothing
within the main tree implements them.

> In addition of course, implementing the protocol natively does allow for
> maximum flexibility.

Maybe, but it should be possible to have a lot of flexibility without
having many projects jump through all sorts of hoops everytime a new
protocol version is created.

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.