"Magnus Hagander" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match