Skip site navigation (1) Skip section navigation (2)

Re: Overhauling GUCS

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: "Decibel!" <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Overhauling GUCS
Date: 2008-06-04 15:10:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Aidan Van Dyk wrote:
> * Andreas Pflug <pgadmin(at)pse-consulting(dot)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,
> 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 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 


In response to


pgsql-hackers by date

Next:From: Michael MeskesDate: 2008-06-04 15:11:49
Subject: Re: keyword list/ecpg
Previous:From: Tom LaneDate: 2008-06-04 14:59:25
Subject: Re: Change lock requirements for adding a trigger

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group