Greg, > The entire target market for such a thing is DBAs stuck on hosted > databases which don't have shell access to their machines.
That's incorrect. The main reason for having a port-based API (such as the SQL command line) for managing your server is that it makes it much easier to manage a large number of servers. Right now, if you want to survey your databases, tables, approx disk space, query activity, etc., you can do that all through port 5432. You can't manage most of your server settings that way, and definitely can't manage the *persistent* settings. When you're trying to manage 1000 PostgreSQL servers, this is not a minor issue. With the growing "cloud" sector, the lack of easy server parameter management is hurting PostgreSQL's adoption for hosted applications. This isn't a new complaint, and is a big part of the reason why 90% of web hosts still don't offer PostgreSQL. I've heard complaints about our manageability problems from more vendors than I can count. HOWEVER, it's completely possible to get a 1st-generation config tool out there without first implementing port-based config access. For one thing, there's Puppet. So that's what I'm intending to do. > I do think you and others make it less likely every time you throw up > big insoluble problems like above though. It's not an insoluble problem. It's a political problem; several people don't want to add this functionality to the project. > As a consequence every > proposal has started with big overly-complex solutions trying to solve > all these incidental issues which never go anywhere instead of simple > solutions which directly tackle the main problem. What, in your opinion, is "the main problem"? I'm not sure we agree on that. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers