Re: Parsing config files in a directory

It sounds like there's a consensus brewing here on what should get done 
with this particular patch now.  Let me try to summarize:

-The new feature should be activated by allowing you to specify a 
directory to include in the postgresql.conf like this:
  includedir 'conf'

With the same basic semantics for how that directory name is interpreted 
as the existing "include" directive.  Tom has some concerns on how this 
will be implemented, with "glob" portability to Windows and error cleanup 
as two of the issues to consider.

-Within that directory, only file names of the form "*.conf" will be 
processed.  More flexibility is hard to implement and of questionable 
value.

-The order they are processed in will be alphabetical.  This allows (but 
doesn't explictly require) using the common convention of names like 
"99name" to get a really obvious ordering.

-The default postgresql.conf should be updated to end with the sample 
includedir statement shown above.  This will make anything that goes into 
there be processed after the main file, and therefore override anything in 
it.

-An intended purpose here is making tools easier to construct.  It's 
impractical to expect every tool that touches files in the config 
directory to do an exhaustive sweep to find every other place there might 
be a conflict and comment them all out.  The fact that pg_settings shows 
users the exact file and line they setting that is the active one is a 
good enough tool to allow DBAs to work through most of the problem cases.

And as far as how it impacts planning:

-A future patch to initdb could move the changes it makes from the primary 
file to one in the config directory.  It might make sense to use a name 
like 00initdb.conf to encourage a known good naming practice for files in 
the config directory; that doesn't need to get nailed down now though.

-This patch makes it easier to envision implementing a smaller default 
postgresql.conf, but it doesn't require such a change to be useful.

-SET PERSISTENT is still a bit away.  This patch assists in providing a 
cleaner preferred way to implement that, and certainly doesn't make it 
harder to build.  The issue of how to handle backing out changes that 
result in a non-functional server configuration is still there.  And 
there's some support for the idea that the SQL interface should do more 
sanity checks to make sure its setting changes aren't being overridden by 
config files parsed later than we might expect from external tuning tools.

Magnus, was there anything else you wanted feedback on here?

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD