Re: Overhauling GUCS

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD