Re: Practical impediment to supporting multiple SSL libraries

* Martijn van Oosterhout (kleptog(at)svana(dot)org) wrote:
> 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?
[...]
> Is there anything else you might need?

Instead of having it hijack the libpq connection and implement the
wireline protocol itself, why don't we work on fixing the problems (such
as the double-copying that libpq requires) in libpq to allow the driver
(and others!) to use it in the 'orthodox' way?

I would have spoken up on the ODBC list if I understood that 'hybrid'
really meant 'just using libpq for connection/authentication'. I really
think it's a bad idea to have the ODBC driver reimplement the wireline
protocol because that protocol does change from time to time and someone
using libpq will hopefully have fewer changes (and thus makes the code
easier to maintain) than someone implementing the wireline protocol
themselves (just causing more busy-work that, at least we saw in the
past with the ODBC driver, may end up taking *forever* for someone to
be able to commit the extra required time to implement).

Thanks,

Stephen