Re: Permanent settings

On Tue, Feb 19, 2008 at 10:34:26AM -0500, Aidan Van Dyk wrote:
> * Magnus Hagander <magnus(at)hagander(dot)net> [080219 10:28]:
>
> > > But if you *need* a way to "set permanent", couldn't you do with with
> > > the following KISS idea?
> > >
> > > Any "set permanent" settings should be *appended* to the main config
> > > file, preferably with a comment line, like:
> > > # Set by user <USER> from client <CLIENT> on <TIMESTAMP>
> > > some_guc option = some_value
> >
> > Are you suggesting we keep appending? So if I set the same parameter 100
> > times, it would show up on 100 rows?
>
> In my opinion, absolutely. It's easy, safe, and the "overhead"
> associated with it is minimal, and not in any critical path "work" path.
> Add to that the fact that the admin can easily clean up the file any
> time he wants too.

I think that's entirely unworkable. While I absolutelyi don't want to break
things for people who use the config file as the primary interface (heck,
*I* am one of those people), it has to be usable for the case it's trying
to fix. And this really wouldn't be.

> > > This does 2 things:
> > >
> > > 1) Eliminates a need for a fancy config parser/editor/rewriter
> > > 2) Makes it very easy to implement
> > > 3) Even allows adminpack to have a "set_permanent" function that could do it
> > > all internally, and not actually need support in the backend core.
> >
> > I should warn you that it's on my radar to try to find the compromises
> > necessary to merge the required functionality away from adminpack and into
> > core for 8.4. Not sure if I'll manage, but I'm certainly going to try.
> > Having to install contrib modules to be able to read your logfiles (just
> > one of several examples) is another thing that most users I've come in
> > contact with hate.
>
> Sure, but the "append via an adminpack function" has the added benifit
> that it can easily be "backported" as a contrib module to the previous
> versions that pgadmin supports as well.

I should clearify that I'm not at all against implementing it as a
function - that may well be a better way. And it would be backportable. I'm
only against the "stick it in adminpack because some people don't want it"
part. It should be made good enough that it's not disruptive for those that
don't want it, and good enough to be in core.

//Magnus