Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings
От | Bruce Momjian |
---|---|
Тема | Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings |
Дата | |
Msg-id | 20140419183533.GB23526@momjian.us обсуждение исходный текст |
Ответ на | Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Apr 19, 2014 at 01:38:16PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > However, in the case of custom variables, you are right that pg_settings > > doesn't show custom variables. > > That is entirely intentional: the reason we do not show placeholder > variables in pg_settings is that we have no accurate information about > them, and so everything pg_settings might show would be fabricated, > and probably wrong, information. > > Once the placeholder has been replaced by a proper declaration of the > GUC variable, it will be shown (with correct info), unless of course > the "proper declaration" includes GUC_NO_SHOW_ALL. Oh, I had forgotten these were placeholders that get replaced later. > What this gets back to is that manually created "custom variables" are an > abuse of a loophole that was only meant to allow postgresql.conf to set > a parameter belonging to an extension module that hasn't been loaded yet. > > If we want to actually support such variables, there should be a way to > properly declare one, including giving its type and other properties > ... and ideally we'd not let you set one without having declared it, > though it's not quite clear how to enforce that without breaking the > parameter-placeholder case. > > > We can do a few things: > > > 1 show custom variables in SHOW ALL and pg_settings > > 2 show custom and other non-SHOW-ALL variables in pg_settings > > 3 document this restriction > > or (4) fix the lack of a declaration capability. But both (1) and (2) > are horrid ideas. There are good reasons for having invented > GUC_NO_SHOW_ALL, and just trashing it is not the answer. > > As for (3), I might be wrong, but I don't think the documentation mentions > the possibility of abusing SET this way at all. Restrictions in > undocumented quasi-features are likewise undocumented. OK, let's wait to see if anyone else complains --- if so, we can document the SHOW ALL and pg_settings behavior in the placeholders section. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: