Re: Practical impediment to supporting multiple SSL libraries

On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
> Well, we had a pure custom implementation of the protocol, had a pure
> libpq based version and after much discussion decided that the best
> version of all was the hybrid as it allowed us to hijack features like
> SSL, Kerberos, pgpass et al, yet not be constrained by the limitations
> of libpq, or copy query results about so much.

Right. Would you see value in a more formal libpq "hijack-me" interface
that would support making the initial connection and then handing off
the rest to something else?

I'm wondering because obviously with the current setup, if libpq is
compiled with SSL support, psqlODBC must also be. Are there any points
where you have to fight libpq over control of the socket?

I'm thinking that such an interface would need to provide the
following:

read (sync/async)
write (sync/async)
getfd (for select/poll)
ispending (is there stuff to do)
release (for when you're finished)

Is there anything else you might need?
--
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.