Message-ID: <4846B06D.8030101@pse-consulting.de>
Date: Wed, 04 Jun 2008 17:10:37 +0200
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Aidan Van Dyk <aidan@highrise.ca>
CC: "Decibel!" <decibel@decibel.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	Greg Smith <gsmith@gregsmith.com>,
	Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org,
	Josh Berkus <josh@agliodbs.com>
Subject: Re: Overhauling GUCS
References: <48409D1E.3070208@agliodbs.com>
	<200806010032.53337.peter_e@gmx.net>
	<Pine.GSO.4.64.0806020452220.26912@westnet.com>
	<17932.1212415926@sss.pgh.pa.us>
	<20080604131810.GH65238@decibel.org>
	<4846A483.8000001@pse-consulting.de>
	<20080604143548.GE14498@yugib.highrise.ca>
In-Reply-To: <20080604143548.GE14498@yugib.highrise.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Aidan Van Dyk wrote:
> * Andreas Pflug <pgadmin@pse-consulting.de> [080604 10:20]:
>
>   
>> Hiding the storage of config parameters opaquely behind an API is 
>> something I've been hating for a long time on win32.
>>     
>
> ;-)
>
>   
>> When reading this thread, I'm wondering if anybody ever saw a config 
>> file for a complex software product that was easily editable and 
>> understandable. I don't know one. If there was one, it'd be nice to know 
>> it so we can learn from it.
>>     
>
> PostreSQL, Apache, X.org
>
> They are all easily editable, and "understandable", in the sense that I
> understand that I'm supposed to edit the line, changing the value
> (following the comments list of accepted values)
>
> They are "less understandable" if you mean that I know the implications
> of any change I make.  But guess what, having those values inputed
> through some other mechanism (like a GUI config file editor, a SQL statement,
> or a nice pgadmin-SQL-hiding-interface isn't going to change that part
> of "understandable".  That part of understandable only comes through
> good documentation and reference material, which is universally
> applicable to any config method.
>   

Right. On the editing side, a column "link" in pg_settings that can be 
used to construct an URL to postgresql.org/docs/xxx#yyy could help 
creating editors that support the user. Whatever a text config file will 
look like, you need to know exactly which parameter to use and where to 
locate it; even structuring parameters won't help too much for the 
typical starter task "I installed pgsql, what to do next".
>   
>> IMHO the best compromise in machine and human readability is an XML 
>> format. It's easily decorateable with comments, easily interpreted and a 
>> pg_settings view could enhance it with even more comments, so an editor 
>> using pgsql functions (to read and write postresql.conf.xml) could be 
>> enabled to supply comprehensive help.
>>     
>
> Well, In my past, I've generally not got around to installing and using
> software that reqired me to edit some jumble of XML.  Ya, maybe I'm
> lucky.  And since I've got a lot invested in PG, I'ld be forced to of PG
> moved to an XML config, but I'ld be forced to kicking and screaming...
>
> I just *know* that I'ld reload/restart postmaster some time, and the
> config file wouldn't be quite correct, and I'ld search for 10 minutes
> trying to find the extra (or lack) ", or missing closing /...  But maybe
> most people are better at parsing XML than me.  And that also may be
> because I've actively avoided it for so long ;-)
>   
Well I'm an XML evangelist either. But the usual "commenting out a 
parameter will reset it to default on reload, no?" caveat isn't funny 
either, or duplicate parameter settings scattered throughout your file.
This may be avoided by *preferably* editing the parameters through pgsql 
itself; the current postgresql.conf file format isn't too machine write 
friendly (as I know since I wrote the pgadmin config file editor). But 
having a config file that can't be used with simple editors at all is a 
nightmare.

Regards,
Andreas