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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
