Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Imran Zaheer <imran.zhir@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Peter Eisentraut <peter@eisentraut.org>, masano@sraoss.co.jp, pgsql-bugs@lists.postgresql.org
Date: 2024-08-17T19:36:55Z
Lists: pgsql-bugs
On Sat, Aug 17, 2024 at 02:12:40PM -0400, Tom Lane wrote: > Imran Zaheer <imran.zhir@gmail.com> 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 had kept this thread in my mailbox from February. > I'd go apply it, but on closer inspection the cross-reference I was trying to apply Peter Eisentraut's patch when gitmaster stopped working. > 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. Agredd. > 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. I think we should apply what Peter supplied, and then we can do a follow-up patch to synchronize. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.