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