|From:||Lou Picciano <LouPicciano(at)comcast(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: pg_stat_ssl additions|
|Views:||Raw Message | Whole Thread | Download mbox|
As we do make significant(?) use of the ssl-ish stuff - though not of the views - should I weigh in?
We do make some not-insignificant use of the sslinfo data, but I see little issue with adding underscores. In fact, ssl-ville is replete with underscores anyway.
Further, I’m not sure exposing details about Cert Issuer, etc. to non-privileged users is much of an issue. For the most part, in most use cases, ‘users’ should/would want to know what entity is the issuer. If we’re talking about client certs, most of this is readily readable anyway, no?
More from PostgreSQL == better.
PS - How you guys doin’? It’s been a while.
> On Nov 28, 2018, at 4:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> On Wed, Nov 28, 2018 at 06:31:59PM +0100, Peter Eisentraut wrote:
>>> Any thoughts from others about whether to rename clientdn to client_dn
>>> to allow better naming of the new fields?
>> Makes sense. The SSL acronyms can get very complex.
> +1. It seems unlikely to me that there are very many applications out
> there that have references to this view, so we can probably get away
> with rationalizing the field names.
> regards, tom lane
|Next Message||Justin Pryzby||2018-11-29 00:40:19||Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0|
|Previous Message||Michael Paquier||2018-11-29 00:16:02||Re: A WalSnd issue related to state WALSNDSTATE_STOPPING|