Re: Parsing config files in a directory
От | Dimitri Fontaine |
---|---|
Тема | Re: Parsing config files in a directory |
Дата | |
Msg-id | 94770055-B1C9-4CCC-978F-8E092B9DFCE9@hi-media.com обсуждение исходный текст |
Ответ на | Re: Parsing config files in a directory (Greg Smith <gsmith@gregsmith.com>) |
Список | pgsql-hackers |
Hi, Phone quoting again... -- dim Le 27 oct. 2009 à 18:06, Greg Smith <gsmith@gregsmith.com> a écrit : > 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. Well choising where to store postgresql.conf is already possible and what debian is doing. My proposal is to build on this: add .d and you find the directory. > >> 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. Historic file loaded last fullfills the need in my mind. > > 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. > include directive or hardwired documented rule: in either case you know what happens when. In one case you can choose, at the expense of having to discover local setup rather than knowing your docs. What I have in mind is for SET PERSISTENT to warn users when settings source is postgresql.conf. >> 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. Yes. But full regexp makes it harder for tools than hardwired rules. > >> 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. Ok if the goal is include dir. If tools and modules are concerned, it Will be easier to SET persistent variable classes then create files like preprepare.at_init.conf e.g. This problem should be seen as an API problem for only automated tools, I think, like Greg Stark said. > >> 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
В списке pgsql-hackers по дате отправления: