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." > I'm starting to wish for a way to do > variable substitution inside postgresql.conf, so we could have defaults > that would actually work if uncommented (eg: $DataDir/pg_hba.conf). > > That would help with auto.conf also. Grumble. I don't think we need this. At least, not for ALTER SYSTEM or conf.d. > > The only problem I see in your snippet above is the "include auto.conf" > > line, which doesn't make any sense because that file would not be found. > > To be honest, I was considering 'include' to be relative to the data > directory and handled similar to how we process recovery.conf, Well, recovery.conf is a special case that doesn't follow to normal rules. > but as we > consider paths in postgresql.conf to be relative to $PWD, that's not > ideal because it'd be different from the rest of the file references. I don't know where you got that idea from, but it's wrong. > While I really like the 'include auto.conf' style, I'm starting to think > it may not be workable after all. Another thing to consider is if the > user decides to change that include line.. What happens when the DBA > tries to do a 'ALTER SYSTEM'? It'd still use the hard-coded auto.conf > file and happily update it, I imagine, but it won't actually get > included... Well, this whole line of discussion started because I objected to the whole code path that was trying to detect whether auto.conf had been parsed, and raised a warning if ALTER SYSTEM was executed and the file wasn't parsed. -- Á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
