* Alvaro Herrera (alvherre@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. 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.
> 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, 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.
In any case, while the current situation sucks, I don't think we can go
changing how relative files are treated in postgresql.conf, nor should
we make the way a path is processed change depending on which GUC is
being set.
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...
Thanks,
Stephen
