Tom Lane writes:
> > - Who is going to maintain the descriptions in this very special "GNU
> > trick" format?
>
> What's special about it? I now understand that I'd misdescribed it, and
> that the fields ought to be named something like "desc" and "extra_desc"
> rather than "short_desc" and "long_desc". But I don't see anything
> wrong with the concept. The short description is also the first
> sentence of the long description; what's unreasonable about that?
It constrains the writer of the description in a way he might not suspect.
For example, we have
check_function_bodies (boolean)
This parameter is normally true. When set false, it disables
validation ...
Then the primary description would become "This parameter is normally
true."
I think there are two ways this can be resolved:
1) Leave it this way, deal with it, but then we can put everything in one
field and let the software parse out the first sentence automatically.
2) Make real separate "short" and "long" descriptions.
> > 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.
>
> Actually I think -M -G corresponds to that set of choices. Are we
> converging on an agreement that we only need that functionality for now?
> If so, what switch shall be used to get it?
I'm thinking that a completely different option name like --dump-config or
--copy-config-info is better than something that implies "help". I would
actually like --help-config to work exactly like --help, so it displays
something like
Options:
...
--sort-mem=INT amount of memory to be used by internal sort
operations and hash tables before switching to
temporary disk files
--...
--
Peter Eisentraut [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
