On Wed, Feb 20, 2008 at 11:20:29AM +0100, Dimitri Fontaine wrote:
> Le mardi 19 février 2008, Gregory Stark a écrit :
> > "Magnus Hagander" <magnus@hagander.net> writes:
> > > Yeah, that may actually be a very good way to implement it. I don't like
> > > the idea of continously appending to an existing file, but if we did have
> > > a separate file with a tightly controlled format that would be doable.
> >
> > +1
> >
> > Separating the automatically written configuration and the explicit user
> > configuration is definitely the right approach. My experience comes from
> > Debian where packages editing their own configuration files is verboten.
> > Otherwise you run into problems reconciling user-made changes and automatic
> > changes.
> >
> > The include file method is workable but isn't perfect. What happens if a
> > user connects with pgadmin and changes a parameter but that parameter is
> > overridden by a variable in the config file?
> >
> > The alternative is to have two files and read them both. Then if you change
> > a variable which is overridden by the other source you can warn that the
> > change is ineffective.
>
> Ok, here's another idea, which only merits could well be to be different :)
>
> What about having a postgresql.conf.d directory containing a file per setting,
> maybe with a subdir per section. If I take Josh Berkus example, we'd have
<snip>
IMHO, if we do that it really sucks for those who use manual configuration
files, to the point of being completely unusable. It could be valid if we
want to support config only through the API, but that's not what people are
asking for.
We need something that's low-impact for existing users, and this certainly
isn't.
//Magnus
