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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
