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: 4846B06D.8030101@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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, 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

In response to

Responses

Browse pgsql-hackers by date

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