Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gS74G-00086K-Km for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Nov 2018 21:08:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gS74F-0004H7-AO for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Nov 2018 21:08:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gS74E-0004H0-Vb for pgsql-hackers@lists.postgresql.org; Wed, 28 Nov 2018 21:08:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gS6xu-0003FG-75 for pgsql-hackers@postgresql.org; Wed, 28 Nov 2018 21:01:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wASL1Vj3014682; Wed, 28 Nov 2018 16:01:31 -0500 From: Tom Lane To: Bruce Momjian cc: Peter Eisentraut , Kyotaro HORIGUCHI , pgsql-hackers@postgresql.org Subject: Re: pg_stat_ssl additions In-reply-to: <20181128173454.GF24817@momjian.us> References: <398754d8-6bb5-c5cf-e7b8-22e5f0983caf@2ndquadrant.com> <20181120.173122.55744021.horiguchi.kyotaro@lab.ntt.co.jp> <01e7dd28-6bcc-5c26-a77d-54340a51633f@2ndquadrant.com> <20181128173454.GF24817@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Wed, 28 Nov 2018 12:34:54 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14680.1543438891.1@sss.pgh.pa.us> Date: Wed, 28 Nov 2018 16:01:31 -0500 Message-ID: <14681.1543438891@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Bruce Momjian 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