Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sfObR-005Haq-OA for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2024 18:56:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sfNvy-0055Gv-Q7 for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2024 18:13:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sfNvy-0055Gn-H1 for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2024 18:13:51 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sfNvv-000AGn-LI for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2024 18:13:50 +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 47HICeZG980690; Sat, 17 Aug 2024 14:12:40 -0400 From: Tom Lane To: Imran Zaheer cc: Laurenz Albe , Peter Eisentraut , masano@sraoss.co.jp, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command In-reply-to: References: <18336-d3652b898b550423@postgresql.org> <94d001ada27f1b39f00370a784395667aa6d44aa.camel@cybertec.at> Comments: In-reply-to Imran Zaheer message dated "Sat, 17 Aug 2024 14:21:58 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <980688.1723918360.1@sss.pgh.pa.us> Date: Sat, 17 Aug 2024 14:12:40 -0400 Message-ID: <980689.1723918360@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Imran Zaheer writes: > The website[1] still shows the redundant LC_COLLATE & LC_CTYPE params. > Are we planning to update them? This patch seems to have fallen through the cracks. I thought I'd go apply it, but on closer inspection the cross-reference to SET seems to indicate we have some more work to do. That's because set.sgml has its own list of "special" names. It'd be fine if SHOW recognized exactly the same list of special names, but it seems to recognize only some of them: regression=# set time zone 'America/New_York'; SET regression=# show time zone; TimeZone ------------------ America/New_York (1 row) regression=# set names 'LATIN1'; SET regression=# show names; ERROR: unrecognized configuration parameter "names" Digging in gram.y, I see that VariableShowStmt actually has these options: SHOW var_name | SHOW TIME ZONE | SHOW TRANSACTION ISOLATION LEVEL | SHOW SESSION AUTHORIZATION | SHOW ALL which is a subset of the special cases in VariableSetStmt (many of which don't seem to be documented anywhere, although I suppose most or all are derived from the SQL spec). I wonder if we ought to try to make that more systematic. I don't see a really good reason why SHOW shouldn't have exactly the same list of special target-name syntaxes as SET. In short: we might end up applying exactly this patch to show.sgml, but we'd have to do some work elsewhere to make the cross-ref to set.sgml not still be a lie. Maybe we should go ahead and commit it as-is anyway, since it's better than what we have. regards, tom lane