Stephen Frost <sfrost@snowman.net> writes:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
>> 1. it is to be read automatically by the server without need for an
>> "include_dir conf.d" option in the main postgresql.conf.
> I am not thrilled with the idea that we're claiming ownership of the
> directory which postgresql.conf happens to reside in and you had better
> not have any 'conf.d' directory in there unless it's the one for PG.
If we were to do this, I'd argue that the location of this hard-wired
config directory ought to be selected by a configure option. And
in fact, I'd argue that the default behavior with no such option be
that there's no such hard-wired directory. That puts it entirely
on the packager to decide what makes sense as a location. In the end
it's going to be the packager's decision anyway --- it's just a matter
of how painful we make it for him to configure it to his distro's
conventions.
On the whole though, I find the argument that we can't configure this
in postgresql.conf to be exceedingly weak. In particular, the idea
that you can puppet-ify a configuration without any knowledge of the
distro you're targeting is ridiculous on its face, as is the idea
that we/postgres can dictate configuration file location conventions
to packagers who have distro rules to follow. There isn't going to
be a "one location to rule them all", and that means the argument
that a location determined by postgresql.conf is too unstable does
not really hold water.
Another point here is that hard-wiring a config directory location
into the executables completely breaks many scenarios for running
multiple clusters with the same executables. Yeah, maybe you'd
like to share most of the same config across all your clusters.
But then again, maybe you wouldn't. The proposed behavior would
make it practically impossible for a test cluster to not pick up
random subsets of the system primary cluster's configuration.
regards, tom lane