Re: Patch for listing runtime option details through server executable (pg_guc)

Peter Eisentraut <peter_e(at)gmx(dot)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