Re: Overhauling GUCS - Mailing list pgsql-hackers

On Fri, 6 Jun 2008, Tom Lane wrote:

> I grow weary of this thread.

If we keep it up for, oh, another three years, then maybe you'll be as 
weary as I am of struggling with problems in this area.  Strinking a 
balance between the wants and needs of people who want a fancy GUI tool 
for configuring database settings with those who want to edit things 
manually is a difficult problem that is not going away.  If this didn't 
keep coming back to haunt me all the time I'd like to forget about it 
myself.

> I will say it once more: I do not believe for one instant that the 
> current formatting of postgresql.conf is the major impediment, or even a 
> noticeable impediment, to producing a useful configuration wizard.

Arguments about formatting change to postgresql.conf are a tangent to the 
central questions here, and having just closed some open comments on that 
I am with you on ignoring those as off-topic the same way I keep 
minimizing "what are the parameters to tune?" comments.

Here are the relevant questions around since the first message that are 
not attracting discussion:

1) Is it worthwhile to expand the information stored in the GUC structure 
to make it better capable of supporting machine generation and to provide 
more information for tool authors via pg_settings?  The exact fields that 
should or shouldn't be included remains controversial; consider "default 
value", "per-session/runtime/restart", and "enum lists" as the list of 
things that are most needed there.

2) Should the sample postgresql.conf file be replaced by a program that 
generates it using that beefed up structure instead, therefore removing 
one file that has to be manually kept in sync with the rest of the code 
base right now?

3) What now makes sense for a way to update database parameters for users 
whose primary (or only in some cases) access to the server is over the 
database port, given the other changes have improved automatic config file 
generation?

> If you wish to prove otherwise, provide a complete wizard except for the 
> parts that touch the config file, and I will promise to finish it.

You do realize that if I provided you with such a sample, the not 
implemented yet "config API" stubs it needs to work would be exactly what 
are suggested to add in the proposal page, right?  I (and Josh) didn't 
just make them all up out of nowhere you know.  I wrote a message here 
already about what the seemingly inevitable path the budding "wizard tool 
hacker" follows and why that leads into some of the changes suggested.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD