Re: Practical impediment to supporting multiple SSL libraries

Stephen Frost wrote:

>* 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).
>
>

Libpq and the psqlodbc driver have walked on another road for a very
long time.
In 6.3 or before, there wasn't a libpq library under Windows. In 6.4 we
had the
libpq library under Windows but it wasn't able to talk to 6.3 or before
unfortunately....
At last in 7.4 the libpq was able to speak both protocol v3 and protocol
v2 but it is
a pretty hard work at least for me to tranfer all the accummulated works
to libpq based
version. I'm not sure what kind of functionalities required for libpq to
make the tranfer
easy. Of cource double-copying issue is big one of them.

regards,
Hiroshi Inue