Re: Parsing config files in a directory

On Tue, 27 Oct 2009, Dimitri Fontaine wrote:

> I parse the current status as always reading files in the
> postgresql.conf.d directory located in the same place as the current
> postgresql.conf file.

Way upthread I pointed out that what some packagers have really wanted for 
a while now is to put the local postgresql.conf changes into /etc rather 
than have them live where the database does.  Allowing the directory to be 
customized makes that possible.  The idea is to improve flexiblity and 
options for DBAs and packagers as long as it's not difficult to implement 
the idea, and allowing for a relocatable config directory isn't that hard.

> Tom had a reserve about allowing the user the control the overloading
> behavior, but it appears that what we're trying to provide is a way for
> tools not to fight against DBA but help him/her. So Greg Stark's idea do
> sounds better: .d/ files are read first in alphabetical order,
> then postgresql.conf is read. If the DBA want to manually edit the
> configuration and be sure his edit will have effect, he just edits
> postgresql.conf. No wondering.

We're trying to make allowances and a smooth upgrade path for old-school 
users who don't want to use this approach.  At the same time, let's be 
clear:  people who do that are going to find themselves increasingly 
cut-off from recommended pracice moving forward.  I want to make it 
possible for them to continue operating as they have been, while making it 
obvious that approach is on its way out.

If you want a future where it's easier for tools to operate, the config 
directory goes last and overrides anything put in the primary 
postgresql.conf in the default config.  Having it inserted as an explicit 
includedir line lets the DBA move it to the front themselves if they want 
to.  One thing we cannot do is make the includedir line implicit.  It must 
be the case that someone who opens a new postgresql.conf file and browses 
it sees exactly what's being done, so they can disable it or move the 
order it happens in around.

> The regexp is still to be agreed upon, [0-9a-zA-Z-_.]+.conf or sth.

This is being left to the author of the code to decide.  There's reason to 
believe that *.conf is going to be hard enough to implement, and that's 
acceptable.  If it turns out that it's easier than expected to make a full 
regex syntax possible here, maybe this should get revisited on next 
review.

> Then the pg_settings view could also embed the comments.

That whole bit you outlined is an interesting idea, but it doesn't impact 
this patch so I'd rather not see it drag discussion out further right now.

> 00-initdb.conf if you want some bikesheding to happen

That's a future patch anyway, we can bikeshed more after it's been 
submitted.  One file per GUC is certainly never going to fly though, it's 
been hard enough getting people to accept going from one file to more than 
one.

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