"Ivan N. Taranov" <i.tara...@postgrespro.ru> writes:
> This is usable for build installable postgresql.conf.SAMPLE. At the
> configure phase, it is possible to include / exclude parameters in the
> sample depending on the selected options (--enable - * / - disable- *
> etc ..)
I'm with Peter on this: you're proposing to complicate matters for
no real gain.
As a former packager, I can readily imagine situations where somebody
wants to adjust the initial contents of postgresql.conf compared to
what's distributed --- I've done it myself. But anybody who's in that
situation has got lots of other tools they can use for the purpose
(patch(1) being a pretty favorite one, since it can also apply other
sorts of code changes). Even more to the point, they've probably got
an existing process for this, which would be needlessly broken by
renaming the file as-distributed.
Also, of the various ways that one might inject a modification,
editing the configure.in file and then having to re-autoconf is
one of the more painful ones, probably only exceeded by trying
to maintain a patch against configure itself :-(
As far as the project's own internal needs go, we do already have
cases where configure's choices need to feed into postgresql.conf, but
having initdb do all the actual editing has worked out fine for that.
I don't think splitting the responsibility between configure time and
initdb time would be an improvement --- for one thing, it'd be more
painful not less so to deal with cases where considerations at both
levels affect the same postgresql.conf entries.
So if you want this proposal to go anywhere, you need a much more
concrete and compelling example of something for which this is the
only sane way to do it.
regards, tom lane
