Re: pg_stat_ssl additions

Поиск
Список
Период
Сортировка
От Lou Picciano
Тема Re: pg_stat_ssl additions
Дата
Msg-id 020C8C7E-B204-4C03-9803-6ACE368DE871@comcast.net
обсуждение исходный текст
Ответ на Re: pg_stat_ssl additions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_stat_ssl additions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
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.

Lou Picciano

PS - How you guys doin’? It’s been a while. 


On Nov 28, 2018, at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Bruce Momjian <bruce@momjian.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: A WalSnd issue related to state WALSNDSTATE_STOPPING
Следующее
От: "Ideriha, Takeshi"
Дата:
Сообщение: minor typo in dsa.c