> Why not harcode in ParseConfigFp() that we should parse the auto.conf file at > the end (and/or if USE_AUTO_CONF is not OFF) instead of hacking > ProcessConfigFile() with data_directory ? (data_directory should be set at > this > point) ... just thinking, a very convenient way to enable/disable that is > just > to add/remove the include directive in postgresql.conf. So no change should > be > required in ParseConf at all. Except maybe AbsoluteConfigLocation which > should > prefix the path to auto.conf.d with data_directory. What I like with the > include directive is that Sysadmin can define some GUC *after* the auto.conf > so > he is sure those are not 'erased' by auto.conf (or by the DBA).
Why do you think DBAs would like an option to disable this feature? I see no point in that. And being able to relocate the parsing of auto.conf to be in the middle of postgresql.conf instead of at the end ... that seems nightmarish. I mean, things are *already* nontrivial to follow, I don't see what would can come from a DBA running ALTER SYSTEM and wondering why their changes don't take. > Also, it looks very interesting to stick to an one-file-for-many-GUC when we > absolutely don't care : this file should (MUST ?) not be edited by hand. > The thing achieve is that it limits the access to ALTER SYSTEM. One file per > GUC allows to LWlock only this GUC, isn't it ? (and also does not require > machinery for holding old/new auto GUC, or at least more simple). This has already been debated, and we have already reached consensus (one file to rule them all). I don't think it's a good idea to go over all that discussion again. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
