On 02/19/2011 01:42 PM, Martijn van Oosterhout wrote:
> On Fri, Feb 18, 2011 at 02:35:42PM -0500, Bruce Momjian wrote:
>>> /* Get the OpenSSL structure associated with a connection. Returns NULL for
>>> * unencrypted connections or if any other TLS library is in use. */
>>> extern void *PQgetssl(PGconn *conn);
>>>
>>> We are under no compulsion to emulate OpenSSL if we switch to another
>>> library. The design intent is that we'd provide a separate function
>>> (PQgetnss?) and callers that know how to use that library would call
>>> that function. If they don't, it's not our problem.
>> Who uses this? ODBC?
> There's a few users, that I can find anyway. psql is one. It uses this
> to get information about the connection, pgadmin does it also for a
> similar reasons I guess.
>
> Adding a seperate function for each SSL library seems odd. It would
> mean that psql would need the headers to every possible SSL library
> because it (in theory) doesn't know which library might be used at
> runtime.
I don't see why. If you plug in a libpq that was compiled against, say,
NSS under a psql that's expecting OpenSSL you'll get a null back instead
of a pointer to an SSL object, but then that would be a silly thing to do.
> ODBC uses it as well. It really uses it for communication. As far as
> Google Code Search can it's the only one that does.
>
> But if the intention is to do it by adding new functions, we can and
> let the ODBC guys sort it out (ERROR: Using incompatable SSL
> connection).
>
>
Yeah. It might make sense to have a library function that tells the
client what SSL library is being used.
cheers
andrew