On Mon, 18 Aug 2008, Gregory Stark wrote:
Because coping with free-form user-edited text is a losing game. People don't consider it because it's a dead-end.
Right, that's impossible technology to build, which is why I had to plan all these screen shots showing tools that handle that easily for Apache's very similar configuration file: http://www.apache-gui.com/apache-windows.html http://kochizz.sourceforge.net/quelques-captures-decran/
Instead you have one file for user-edited configuration and a separate file for computer generated configuration.
It wouldn't be so difficult if the system generated postgresql.conf didn't have all this extra junk in it, which is part of what an overhaul plans to simplify. The way the file gets spit out right now encourages some of the awful practices people develop in the field.
A tuning interface can't be turing complete and detect all possible misconfigurations. To do that it would have to be as complex as the server.
Thank you for supporting the case for why changes need to be to the server code itself, to handle things like validating new postgresql.conf files before they get loaded. I try not to bring that up lest it complicate things further.
The entire target market for such a thing is DBAs stuck on hosted databases which don't have shell access to their machines.
I've never setup a hosted database on a system I don't have shell access to, so I have no idea where you get the impression that was a primary goal of anything I've said. It just so happens that improving what tuning you can do over port 5432 helps that crowd out too, that's a bonus as I see it.
Ask me about EnterpriseDB's On-Demand Production Tuning
...nah, too easy, I'll just let that go. -- * 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
