Re: Parsing config files in a directory

Hi,

Phone quoting again...

--
dim

Le 27 oct. 2009 à 18:06, Greg Smith <gsmith(at)gregsmith(dot)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(at)gregsmith(dot)com http://www.gregsmith.com
> Baltimore, MD