On Wed, Jan 17, 2018 at 6:48 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> What would be much worse is if a particular GUC did not have a matching
> concept in the library. Say if an SSL library did not have a concept of
> priority strings and instead used some other concept affecting cipher
> suite choice (not sure how that would like). That would make our GUC
> useless or confusing, possibly forcing us to translate the strings in
> some strange way.
I think that's pretty likely to happen, which is why I favor renaming
all of the SSL stuff to openssl_* and then having gnutls_* and
similarly for other implementations. It's not going to be fun to
document that there's this single GUC which, depending on some
compiler flag which you don't know anything about, takes a
differently-formatted value and maybe does different stuff. That's
what we'll end up with even for absolutely simple things like
ssl_ciphers, because it's extremely unlikely that every SSL library on
earth uses the same format that OpenSSL does. Worse yet, users are
not going to intrinsically know which SSL implementation was compiled
into the server they have.
Now, if we can tell them something like this, then things will be better:
PostgreSQL can be compiled against any of several SSL implementations.
Currently, PostgreSQL supports OpenSSL, GnuTLS, AwesomeSSL, and
TLSBlah. Each of these implementations is controlled by a different
group of settings; only settings for the SSL implementation against
which the server is compiled will exist. For OpenSSL, the controlling
settings are openssl_thingy, openssl_thang, and openssl_thunk. For
GnuTLS, the controlling settings are .... etc. etc.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company