Re: Practical impediment to supporting multiple SSL libraries

Martijn van Oosterhout <kleptog@svana.org> writes:
> 1. Changing it to always return (void*), irrespective of SSL
> ...
> Personally, I'm in favour of 1, because then we can get rid of the
> #include for openssl, so users don't have to have openssl headers
> installed to compile postgresql programs.

I like that too.  I've never been very happy about having libpq-fe.h
depending on USE_SSL.

There is a more serious issue here though: if we allow more than one SSL
library, what exactly can an application safely do with the returned
pointer?  It strikes me as very dangerous for the app to assume it knows
which SSL library is underneath libpq.  It's not at all hard to imagine
an app getting an OpenSSL struct pointer and trying to pass it to GnuTLS
or vice versa.  To the extent that there are apps out there that depend
on doing something with this function, I think that even contemplating
supporting multiple SSL libraries is a threat.
        regards, tom lane