Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4lra-00058k-Ef for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Jul 2021 15:04:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m4lrZ-00067j-9d for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Jul 2021 15:04:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4lrX-00067b-TY for pgsql-bugs@lists.postgresql.org; Sat, 17 Jul 2021 15:04:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4lrW-0006UX-1b for pgsql-bugs@lists.postgresql.org; Sat, 17 Jul 2021 15:04:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 16HF4Ell066576; Sat, 17 Jul 2021 11:04:14 -0400 From: Tom Lane To: Bharath Rupireddy cc: "leiyanliang@highgo.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17077: about three parameters in postgresql 13.3 In-reply-to: References: <17077-ade8e166a01e1374@postgresql.org> <202107171236202362593@highgo.com> <56876.1626531624@sss.pgh.pa.us> Comments: In-reply-to Bharath Rupireddy message dated "Sat, 17 Jul 2021 20:20:39 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66574.1626534254.1@sss.pgh.pa.us> Date: Sat, 17 Jul 2021 11:04:14 -0400 Message-ID: <66575.1626534254@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bharath Rupireddy writes: > On Sat, Jul 17, 2021 at 7:50 PM Tom Lane wrote: >> The code is operating as designed. It does seem odd that there's no >> mention of these variables in the documentation, though. > I think the point that the 3 GUCs have no explanation in the docs but > still show up in the pg_settings was discussed at [1]. There, we > wanted to add GUC_NO_SHOW_ALL for 3 of them. I still would prefer it > because the 3 GUCs will only be used internally(?). I've concluded that we should just document them (and am working on that right now). It's certainly true that there is a use-case for reading them: libpq does "SHOW transaction_read_only", for example. And since we've gone to the trouble of making SET of one of these equivalent to SET TRANSACTION, we should probably just document that it is. regards, tom lane