Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Peter Eisentraut <peter(at)eisentraut(dot)org>, masano(at)sraoss(dot)co(dot)jp, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command
Date: 2024-08-17 18:12:40
Message-ID: 980689.1723918360@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Imran Zaheer <imran(dot)zhir(at)gmail(dot)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'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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2024-08-17 19:36:55 Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command
Previous Message Tom Lane 2024-08-17 16:45:32 Re: BUG #18585: Date/time conversion functions are not protected against integer overflow