Re: Improving postgresql.conf - Mailing list pgsql-hackers

From Michael Glaesemann
Subject Re: Improving postgresql.conf
Date
Msg-id 457109FD-BF68-11D8-846A-000A95C88220@myrealbox.com
Whole thread Raw
In response to Re: Improving postgresql.conf  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Improving postgresql.conf
Re: Improving postgresql.conf
List pgsql-hackers
On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:

>>> The proposal is to remove the comments from postgresql.conf (like
>>> Apache) so all entries will be active.  The downside is that it will 
>>> not
>>> be possible to determine which values were modified from their 
>>> defaults.
>
> One thing that truly annoys me about postgresql.conf is say I unhash 
> an option and set it to something.  Then I reload.  Then I edit the 
> conf and hash it out again, then I reload.  Of course, the option 
> still has my old value.  This is really annoying and I've wasted lots 
> of time trying to figure out what's going on.

A habit I've gotten into for editing config files that have commented 
defaults is to copy the line with the setting, uncomment the copied 
line, and change it to my setting.

Would it help to have two lines in the config file for each setting, 
one with the default (comment) and one with the actual setting? So for 
example, the postgresql.conf would ship with something like this:

#tcpip_socket = false       #default
tcpip_socket = false

If the user wants to connect via tcp_ip, they can edit it like this:
#tcpip_socket = false       #default
tcpip_socket = true

The default is still there for reference, and they can see what the 
current setting is. Granted, there's redundancy in having the commented 
line and the uncommented line (if I understand the defaults correctly), 
but it might be useful redundancy. Users would have easy reference to 
what the "factory settings" are.

Michael Glaesemann
grzm myrealbox com



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: #postgresql report
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Improving postgresql.conf