Re: SQL command to edit postgresql.conf, with comments

On 10/13/2010 10:25 AM, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> You're not alone on this at all: I agree 100%. I don't like your
>> proposed syntax, but I completely agree with your concern. I don't
>> see what's wrong with having the initial contents of postgresql.conf
>> look like this (these are the settings that are uncommented by default
>> on my machine):
>> # type "man postgresql.conf" for help on editing this file
>> max_connections = 100
>> shared_buffers = 32MB
>> datestyle = 'iso, mdy'
>> lc_messages = 'en_US.UTF-8'
>> lc_monetary = 'en_US.UTF-8'
>> lc_numeric = 'en_US.UTF-8'
>> lc_time = 'en_US.UTF-8'
>> default_text_search_config = 'pg_catalog.english'
> I'm not sure if anybody is particularly against the initial contents
> looking like that. The big problem, which both you and Dimitri are
> conveniently ignoring, is that if people are allowed to hand-edit
> the file they are going to introduce comments that no mechanical
> parser will do a nice job of preserving. And they're not going to be
> happy when SET PERMANENT has a side-effect of throwing away their
> comments.
>
> I don't see anything particularly wrong with Josh's proposal of keeping
> machine-generated and person-generated text in separate files. Dimitri
> complains that the behavior will be confusing if there are conflicting
> settings, but I think that's hogwash. We already have the ability for
> pg_settings to tell you which file, and even which line, set the active
> value of the setting. It's not going to be hard for people to figure
> that out.

+1. Preserving the comments when you change the value could make the
comments totally bogus. Separating machine-generated values into a
separate file makes plenty of sense to me.

Which one wins, though? I can see cases being made for both.

cheers

andrew