"Magnus Hagander" <mha@sollentuna.net> writes:
>> Other than DN and CN, what else would people want?
> Issuer (name and certificate), validity dates, basic constraints, key
> usage, posslby fingerprint.
I think that way madness lies --- do we really want to commit to
re-inventing an SSL API that will cover anything someone might want
to do with either underlying library? Moreover, this does not fix
the problem: an existing app that thinks it can pass the returned
pointer to an OpenSSL routine will still crash the moment a GnuTLS
version of libpq is put under it. Case in point: psql, as currently
coded.
An idea that just occurred to me is to define PQgetssl as "return SSL*
if we are using OpenSSL for this connection; else return NULL". Then
add a parallel routine (maybe PQgetgnussl?) defined as returning the
equivalent GnuTLS handle, only if we are using GnuTLS for this
connection. (Presumably, in any one build of libpq, one of the pair of
routines would be an always-returns-null stub.)
The advantage of this is that an app knows what it'll get, and an app
that's only familiar with one of the two SSL libraries will not be
given a pointer it can't use.
I'd still want to adopt Martijn's idea of declaring both of 'em as
returning void *, to avoid depending on other packages' include files.
regards, tom lane
