On Tue, Aug 20, 2013 at 10:02 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Stephen Frost escribió: >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> > Well, all the relative paths in include/includedir directives would be >> > relative to the directory specified by the -c config_file param, which >> > makes perfect sense. So the conf.d would work fine in your example. >> >> Why would include/includedir directives be relative to where the >> 'config_file' GUC is set to instead of relative to where all the other >> GUCs in postgresql.conf are relative to? That is a recipe for >> confusion, imv. >> >> Of course, the current situation is quite terrible anyway, imv. Having >> the GUCs be relative to whereever the user happens to run pg_ctl from is >> pretty ugly- not to mention that the commented out 'defaults' won't >> actually work if you uncomment them because the *actual* default/unset >> value *is* in the data directory. > > Uh? See the docs: > http://www.postgresql.org/docs/devel/static/config-setting.html#CONFIG-INCLUDES > > " ... the postgresql.conf file can contain include directives, ... > If the file name is not an absolute path, it is taken as relative to > the directory containing the referencing configuration file."
You are right and I have checked code as well, it works in above way for include directives. Now the question I have in mind is that even if we can't directly use include directive to enable/disable Alter System and reading of auto file, how would a new GUC enable_alter_system can solve all the things. It can allow/disallow Alter System command, but how about reading of auto file? If we directly read auto file without considering enable_alter_system, it can lead to chaos due to some un-safe values, on the other side if we want to consider enable_alter_system before reading file, it can complicate the ProcessConfigFile() code. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers