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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
