Re: postgres --help-config

Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It'd be better if we could get it right the first time, with the
> > understanding that the output format is not very negotiable at this
> > late hour. But as best I can tell, most of the unhappiness is with the
> > design of the switch set, which is not something I want to defend in
> > detail. There's a lot there that isn't needed for the RHDB tool as I
> > understand it, and I think that altering the switches used to get the
> > output that the tool does need would still be a feasible change from the
> > tool's point of view.
>
> I have some more questions:
>
> - When the set of GUC properties (when to set, how to set, etc.) change,
> what is the upgrade path? Remember that we change those a lot.

You mean when we add another member the GUC structure? I assume the
tool is first going to have to test for the PostgreSQL version, and
handle each version slightly differently --- I don't see another way.
Perhaps that's what the 'headings' flag was for, but I don't think that
really helps much --- there has to be code to understand what that new
column means.

> - Who is going to maintain the descriptions in this very special "GNU
> trick" format? I can happily agree if we had a short description that
> is shown in an overview list, and an long description that is shown when
> the option is opened up in its own window, but I don't agree with with
> the current format. At least not in the way it was explained to me,
> maybe I'm misunderstanding.

Are you talking about the descriptions in the guc.c file that are part
of the GUC structures? I think we are heading in a direction where we
should be pulling descriptions out of SGML like we do with psql help,
and using that to load the GUC structures with descriptions. I don't
see another long-term solution, do you?

> > I would be in favor of simplifying the supported switch set to the
> > minimum needed by Red Hat's tool (the equivalent of -G -M if I
> > understood Fernando correctly), and re-adding complexity in future
> > when and if it's shown to be needed. But we need to make a decision
> > about this now. Preferably yesterday.
>
> I propose we rip out everything except --help-config -m that shows the
> information in the "machine-readable" tab separated format without
> headers. If someone can answer the two questions above.

I just proposed that as --help-config-raw. I don't think we want to
head in the direction of having flags like -m be useful only if
preceeded by a --help-config flag --- it is too confusing. I think
--help-config and --help-config-raw is all we will ever need.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073