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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD