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