Re: Practical impediment to supporting multiple SSL libraries - Mailing list pgsql-hackers

From Dave Page
Subject Re: Practical impediment to supporting multiple SSL libraries
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4011C9C64@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Practical impediment to supporting multiple SSL libraries  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Practical impediment to supporting multiple SSL libraries  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers

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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: plpgsql by default
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries