Re: Parsing config files in a directory
От | Robert Haas |
---|---|
Тема | Re: Parsing config files in a directory |
Дата | |
Msg-id | 603c8f070910280429p4bfb4a64p7e1c3ca54611a8bc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parsing config files in a directory (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Tue, Oct 27, 2009 at 11:40 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 10/27/09 8:24 PM, Robert Haas wrote: >> read the old postgresql.conf and >> write it back out to a new file line by line. If, in the process of >> doing this, you find a setting for the variable you're trying to >> change, then write out the new line in place of the original line. > > You've hit the problem on the head right there. The requirement to do > something like that is *exactly* the problem which makes writing > config-management tools hard/impossible. > > If you require that a tool (or SET PERISTENT) parse through a file in > order to change one setting, then you've just doubled or tripled the > code size of the tool, as well as added a host of failure conditions > which wouldn't have existed otherwise. I think you're just trading one set of failure conditions for another.Now instead of having one unparseable configurationfile you're going to have a whole pile of them with possibly-conflicting settings. > You're hearing from the people who are working on tools: requiring that > any tool parse a hand-written config file is a non-starter. Yep: and I'm baffled by that, because I understand neither why it's hard nor what the reasonable alternatives are. The algorithm I just proposed can be implemented by a very short Perl script. But my bafflement doesn't (and isn't intended to) prevent others from implementing what they like. As Tom is fond of saying (and it's 10x more true of me), I'm not the only vote here. ...Robert
В списке pgsql-hackers по дате отправления: