Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

> 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