Re: Patch for listing runtime option details through server executable (pg_guc)
От | Tom Lane |
---|---|
Тема | Re: Patch for listing runtime option details through server executable (pg_guc) |
Дата | |
Msg-id | 20906.1057019434@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for listing runtime option details through server (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Patch for listing runtime option details through server executable (pg_guc)
(aahmed@redhat.com)
|
Список | pgsql-patches |
Peter Eisentraut <peter_e@gmx.net> writes: > If the option is named --long-help, I'd expect a longer version of > --help, which this is not. The name should probably involve "help" > and "config" to make it clearer what you get. (Personally, I think > "help" should go before the qualifying word, but there may be other > opinions.) Yeah, I haven't thought of a real satisfactory name either. Do you like "--help-config"? > If, on the other hand, we like the code to know about categories, > should this code be capable of generating the sample file > automatically? There was something about that in the back of the mind, but I'd prefer to take that as a long-term goal rather than try to make it happen right now. > To mark up string literals, where you use translatable(), there is > already a standard function gettext_noop() available. Ah. The translatable() was my suggestion --- I'd forgotten we had another macro already defined. (But why doesn't nls.mk mention it? Or is that name built into the gettext tools?) > There is already a file guc.c, why should there be a file pg_guc.c > now? That doesn't make sense; the names should be differentiated > better. The name pg_guc.c is left over from the original intent of having a standalone tool named pg_guc. We could fold it together with guc.c, but I think it is cleaner to keep it as a separate file. If you have a better name for it, that's fine with me... > Why have various things been moved from guc.h to guc_vars.h, which > seems to just split things up uselessly? So that pg_guc.c can get at the constant tables in guc.c. Admittedly, this would go away if we fold the two together, but I think that's the wrong thing. pg_guc is still a small standalone program in concept ;-) ... it is just sharing an executable with the backend. > Why are there long explanations in some cases only? Do you plan to > add others later? I also think the messages should be made more > consistent in various ways, but that can be done later. Yeah, I had some editorializing to do too. This is not on the critical path though. > Should options not for general use (e.g., session_auth_is_superuser) > be hidden from this tool? Are they? What other provisions of this > kind does this tool make? The original intent of the standalone tool was to display stuff that could usefully be set in postgresql.conf, and I think it's important to maintain that as an available behavior (though I wouldn't object to making other subsets available as well). The patch includes a couple more flag bits to try to identify the behaviors of various variables. (I've not checked Aizaz' settings for the flags though, there might be some mistakes.) regards, tom lane
В списке pgsql-patches по дате отправления: