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
