Peter Eisentraut <peter_e@gmx.net> writes:
> We are currently maintaining information about configuration parameters
> in at least three places: the documentation, guc.c, and
> postgresql.conf.sample. I would like to generate these from a single
> source. Computationally, this is not very challenging, it's just a bit
> of work. I imagine as the source an XML file with a custom schema; see
> below for an example. I think this is the best source format because
> it allows integrating the DocBook-formatted descriptions without too
> much trouble and it allows for file format validation. An alternative
> might be m4 but that would not offer these features. To process this
> we'd use XSLT stylesheets run through xsltproc. We'd run this part
> during the tarball building phase, so users would not need it.
That's fine for users, but what new demands are you about to place on
developers? Does this require tools not already needed in order to
build from a CVS pull? (There's sure no xsltproc on this machine...)
ISTM the last thing we need at the moment is to put more obstacles in
the way of new developers, or for that matter new buildfarm entrants.
The m4 idea seems attractive to me because that's already effectively
required as part of the autoconf infrastructure (and I think bison
uses it too these days).
A similar issue that's been bothering me for awhile is that it'd be a
lot less error prone if keywords.c and the keyword list productions in
gram.y were generated off a common declarative source (which might as
well produce the keyword documentation appendix too). But again, I'm
not sure what kind of price I want to pay in infrastructure for that.
regards, tom lane
