Kevin Brown <kevin@sysexperts.com> writes:
> 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)?
Keep in mind that initdb doesn't currently *need* to put the datadir
location into the config file. It *will* need to do so if we separate
config and data dirs. Or at least, *somebody* will need to do so.
It's not apparent to me how it simplifies life not to have initdb do it.
Especially when there are other configuration items that initdb should
or already does record: locale settings, database encoding. And we
have already been talking about improving PG's self-tuning capability.
initdb would be the natural place to look around for information like
available RAM and adjust the config-file settings like sort_mem
accordingly.
Basically, the notion that initdb shouldn't write a config file seems
like a complete dead end to me. It cannot possibly be more convenient
than the alternatives. We'd be giving up a lot of current and future
functionality --- and for what?
> 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.
If we do it the way I suggested (dump into the datadir, which is
initially empty, same as always) then it cannot overwrite your existing
config files. Think of it as providing a suggested config file to
compare against what you have.
regards, tom lane