|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] GnuTLS support|
|Views:||Raw Message | Whole Thread | Download mbox|
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... Worse yet, users are
> not going to intrinsically know which SSL implementation was compiled
> into the server they have.
That is a really good point. For precedent, note that darn near nobody
seems to know whether their psql contains readline or libedit. If we
force the issue by giving the settings different names, then they'll be
forced to figure out which SSL implementation they have.
On the other hand, you could argue that there are more user-friendly
ways to expose that information than demanding that users play twenty
questions with their config files. I'd at least want us to recognize
when somebody tries to set "openssl_foo" in a gnutls implementation,
and respond with "you need to twiddle the gnutls_xxx variables instead"
rather than just "unrecognized configuration parameter". Maybe that'd
be good enough, though.
Also, this isn't really a good argument against using uniform names
for parameters that every implementation is certain to have, like
regards, tom lane
|Next Message||David Rowley||2018-01-18 03:14:51||Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning|
|Previous Message||Robert Haas||2018-01-18 02:33:13||Re: [HACKERS] GnuTLS support|