Tom Lane wrote:
> Currently, I don't need to do anything more than set PGDATA or say -D
> to initdb in order to set up the data directory wherever I like. I also
> don't need to worry about whether I'm selecting the wrong config file.
So in your case, what's the advantage of having initdb write anything
to a config file, when you're probably also relying on PGDATA or -D to
start the database (if you're not, then fair enough. But see below)?
I'd expect initdb to initialize a database. If I were running initdb
without a lot of foreknowledge of its side effects, I think I'd
probably be a bit surprised to find that it had touched my config
file. Initdb doesn't have prior knowledge of how you intend to
start the database so that it refers to the database initdb just
created, so it can't really know whether it's desirable to touch the
config file.
If it's desirable for initdb to be able to write to the config file,
wouldn't it be more appropriate for that to an option that has to be
explicitly enabled on initdb's command line? I don't know how often
you'd want it to write into the config file for your purposes, but
having it do so automatically seems to violate the principle of least
surprise.
--
Kevin Brown kevin@sysexperts.com