Kevin Brown <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster