Re: A successor for PQgetssl

On Mon, Apr 17, 2006 at 11:07:26AM -0400, Stephen Frost wrote:
> I didn't really understand Tom's point here either... In order to not
> break psqlODBC when libpq is compiled with GnuTLS we'd have to code up
> support for returning an SSL* from the GnuTLS library that would work
> for all the OpenSSL functions which just isn't going to happen... I
> agree that we probably shouldn't go out of our way to break psqlODBC
> when libpq is compiled with OpenSSL (and so we shouldn't really change
> PQgetssl but mark it obsolete and ask that people don't use it and
> provide some other way for psqlODBC to do what it wants, or not, perhaps
> return NULL when using GnuTLS or '0x1', or not define it when libpq is
> compiled with GnuTLS...).

Just mark PQgetssl() obsolete. We have to return a NULL or a valid
pointer, otherwise existing programs will just crash. The major reason
for this PQgettlsinfo() function is so people can actually *know* which
library is active. Consider stuff like this:

PQgetssl() not NULL -> using openssl
PQgetgnutls not NULL -> using gnutls
else
not using ssl OR using some unknown library

That's not a way to design an interface. This PQgettlsinfo() would tell
you, one way or the other, if there is a TLS library in use. Give the
user the certificates and the cipher and if the user wants more info,
they can use the SSL library of their choice to get the information
they want.

Note, some of the info there is not stuff you can actually get from
the PQgetssl() function currently anyway. You can't ask the SSL library
easily if we provided a certificate during authentication. libpq knows
this easily.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)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.