Re: Overhauling GUCS - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Overhauling GUCS
Date
Msg-id 4848D447.10005@enterprisedb.com
Whole thread Raw
In response to Re: Overhauling GUCS  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Overhauling GUCS  ("David E. Wheeler" <david@kineticode.com>)
Re: Overhauling GUCS  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
David E. Wheeler wrote:
> On Jun 5, 2008, at 14:47, Greg Smith wrote:
> 
>> This is why there's the emphasis on preserving comments as they pass 
>> into the GUC structure and back to an output file.  This is one of the 
>> implementation details I haven't fully made up my mind on:  how to 
>> clearly label user comments in the postgresql.conf to distinguish them 
>> from verbose ones added to the file.  I have no intention of letting 
>> manual user edits go away; what I'm trying to do here (and this part 
>> is much more me than Josh) is make them more uniform such that they 
>> can co-exist with machine edits without either stomping on the other.  
>> Right now doing that is difficult, because it's impossible to tell the 
>> default comments from the ones the users added and the current comment 
>> structure bleeds onto the same lines as the settings.
> 
> How about a simple rule, such as that machine-generated comments start 
> with "##", while user comments start with just "#"? I think that I've 
> seen such a rule used before. At any rate, I think that, unless you have 
> some sort of line marker for machine-generated comments, there will be 
> no way to tell them apart from user comments.

What comments do we consider machine-generated? Just the ones used to 
comment out settings, like

#shared_buffers = 32MB

or something else?

If the automatic tool lets alone all other kind of comments, I think 
we're fine. In fact, it wouldn't necessarily need to modify those 
comments either, it could simply add a new setting line below that:

#shared_buffers = 32MB
shared_buffers = 1024MB

For extra safety, it could comment out old settings, perhaps with 
something like this:

#shared_buffers = 32MB
#shared_buffers = 1024MB  # commented out by wizard on 2008-06-05
shared_buffers = 2048MB

This would preserve a full change history in the file. It would become 
quite messy after a lo of changes, of course, but a user can trim the 
history by hand if he wants to.

Or perhaps we should explicitly mark the settings the tool has 
generated, and comment out:

#shared_buffers = 32MB   # commented out by wizard on 2008-06-05
shared_buffers = 1024MB  # automatically set by wizard on 2008-06-05

That way the tool could safely replace automatically set settings, 
without replacing manually set ones without leaving a clear trace of 
what happened.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: orafce does NOT build with Sun Studio compiler
Next
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS