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
