Re: Permanent settings

Aidan Van Dyk wrote:
> * Magnus Hagander <magnus(at)hagander(dot)net> [080220 14:03]:
>
> > > I think the first step is really for some people to show code that
> > > "rewrites" the config file changing a setting reliably and correctly.
> >
> > But what we're donig now is discussing *how to do that*, no?
>
> Sort of, but of course, we're getting caught up in extra syntactic
> stuff..
>
> If someone *is* writing this config-rewriter now, these are the types of
> quesitons I think they need to be asking, some of which have been
> touched on, some not. But I think a first cut could pick any answer for
> them, and still be easily adaptable...
>
> 1) What file to we "rewrite"? Main one, or some other specified one?

I think the file that is the source for the option that we write.
If a parser can determine what is the last occurence of the option in
the configuration files - this can be done as well for SET PERMANENT.

> 2) Do we follow includes to find our setting?

Yes and no. We have to follow includes, otherwise the effect of remote
changes to the option won't be the same as the effect of manual changes
via the text editor. However, following the previous proposals we can
store a file that is the source of the option, i.e. the file that sets
the value for the option that is active for the time of SET PERMANENT.

> 3) Which setting do we change, the 1st, or last found in the config
> file?

I think that is active, presumably last.

> 4) What do we do about comments *on the same line* as the setting we're
> changing (I'm assuming all other lines won't be touched)

Just drop them. Another idea is to comment the old value, preserving
the old inline comments, and put a new value to the next line, but
I don't really like it since eventually it would make the config file
unreadable with lots of 'dead' commented values.
Anyway, we can't parse that comments unless we teach the backend to speak
several hundreds of available world languages, that is not what the
database development about :).

> 5) How do we want to handle errors like "ENOSPC", or EPERM (I'm assuming
> of course that the file rewrite will be a tmp+rename, not a trunc+write)

don't change anything, return ERROR.

> 6) Do we want to distinguish between "restart only" settings, and
> reloadable settings, and if so, how?

I think now, since we don't digstinguish between them when writing the
config file manually.

--
Alexey Klyukin http://www.commandprompt.com/
The PostgreSQL Company - Command Prompt, Inc.