Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command
От | Bruce Momjian |
---|---|
Тема | Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command |
Дата | |
Msg-id | ZsD717W96tCNQCAI@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #18336: Inconsistency in PostgreSQL 16 Documentation for SHOW Command (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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.
В списке pgsql-bugs по дате отправления: