Re: Overhauling GUCS
От | Andreas Pflug |
---|---|
Тема | Re: Overhauling GUCS |
Дата | |
Msg-id | 4846B06D.8030101@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Overhauling GUCS (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: Overhauling GUCS
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: