Re: Practical impediment to supporting multiple SSL libraries

On Fri, Apr 14, 2006 at 11:22:23AM -0400, Tom Lane wrote:
> Greg's observation is correct, so maybe we are overthinking this
> problem. A fair question to ask is whether psqlODBC would consider
> going back to a non-hybrid implementation if these features did exist
> in libpq.

Well, it is an issue. It's not a specific problem per se that psqlODBC
implements the protocol itself. If you remember right back at the
beginning of the thread (see subject) there was the issue of users
using libpq to connect and then continuing themselves. The issue being
that the pointer from PQgetssl() wouldn't work if we had different SSL
libraries available.

Perhaps a far easier approach would be to indeed just have a hijack
interface that provides read/write over whatever protocol libpq
negotiated. Then people could write their own protocol parsers to suit
their needs while still using libpq for the connection. Have the cake
and eat it too?

Note, we would have to allow users of libpq to force the version,
otherwise libpq would connect using a version the user doesn't
understand.

> Please mention some specific examples. We need some examples as a
> reality check.

Well, psqlODBC is the obvious case. Besides that it becomes tricky. I
would think that DBI::Pg could benefit, I just don't understand the
code well enough to know if it's directly useful.

I would expect drivers in particular to benefit and some complex
applications, but if you're asking for specific examples, I don't have
any...

That doesn't change the fact that it's a nice idea, just definite
benificiaries are harder to find.

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.