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

From Robert Treat
Subject Re: Improving postgresql.conf
Date
Msg-id 200406161125.07362.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Improving postgresql.conf  (Michael Glaesemann <grzm@myrealbox.com>)
List pgsql-hackers
On Wednesday 16 June 2004 03:39, Michael Glaesemann wrote:
> 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.
>

Misery must love company, because I do the same thing.  Ideally I'd like to go 
further, like pulling the info out of the sgml, but even this would be an 
improvement imho. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Improving postgresql.conf
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: OWNER TO on all objects