Kevin,
> I'm talking about how the decision should be made as to which takes
> precedence. It's fine to document which one *was* chosen, but that
> doesn't eliminate the problem of conflicting settings making a mess.
> Someone else (Robert maybe?) gave an explicit example of how three
> files could have overlapping settings. Of course, *my* tool will name
> its configuration file " !.conf".
Hey, if a DBA wants to do that, then it's fine with me. They can check
pg_settings afterwards to find out which was chosen.
The precedence issues you (and Robert) are citing are no different from
what we have currently in a single file. I absolutely can't tell you
the number of hacked-up postgresql.conf files I've seen with the same
setting appearing in more than 3 places. And with the conf file being
over 1000 lines long, it's easy to miss that someone or some tool added
another instance of the variable at the bottom.
Plus we already support includes of single files. Why is an include of
a directory controversial? If someone doesn't want to use it, they
don't have to.
If someone here thinks writing a tool which reliably parses and
re-writes a hand-written PostgresQL.conf and runs on all the OSes we
support is *easy*, then please write it for me! I'll happly use such a
tool. But after wasting a couple dozen hours on the problem, I won't
write one.
Otherwise, please let us have our directory so that we can experiment
with easy-to-write-and-revise autoconfig tools.
--Josh Berkus