Re: postgres --help-config - Mailing list pgsql-hackers

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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073