Practical impediment to supporting multiple SSL libraries

Just quickly going through what might be needed to support multiple SSL
libraries revealed one big problem in libpq-fe.h.

#ifdef USE_SSL
/* Get the SSL structure associated with a connection */
extern SSL *PQgetssl(PGconn *conn);
#else
extern void *PQgetssl(PGconn *conn);
#endif

The return type of the function changes depending on whether SSL is
compiled in or not. :( So, libpq exposes to its users the underlying
SSL library, which seems wrong. Now, options include:

1. Changing it to always return (void*), irrespective of SSL
2. Creating a PGsslcontext type that varies depending on what library
you use (or not).
3. Removing the function entirely because the only user appears to be
psql (in tree anyway).
4. Only declare the function if the user has #included openssl
themselves.

Or alternatively we could do nothing because:

5. It's not a problem
6. It's a backward incompatable change

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. Options 2, 3 and 4 have
varying levels of evilness attached. However, I can see how 5 or 6
might be attractive.

Thoughts?
--
Martijn van Oosterhout   <kleptog@svana.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.