Re: Practical impediment to supporting multiple SSL libraries

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Martijn van Oosterhout
> Sent: 12 April 2006 16:48
> To: pgsql-hackers(at)postgresql(dot)org
> Subject: [HACKERS] 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

The next version of psqlODBC (that has just gone into CVS tip after
months of work and debate) uses it, and would break almost completely
should it be removed, therefore any backwards incompatible change should
be avoided imho. And 2 or 4 could cause chaos for Windows users if
different DLL builds get mixed up.

Regards, Dave.