Re: Patch for listing runtime option details through server executable (pg_guc) - Mailing list 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