"Josh Berkus" <[EMAIL PROTECTED]> writes: > 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.
This I don't understand. If you're managing lots of servers running lots of software the last thing you want to have to do is write a custom method for updating the configuration of each service. In that use case you would prefer to just use rsync/svn/git to push the new config file to all the machines anyways. > 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. These are both use cases which fall in the category I described where you want to allow users to configure the system through an automated interface. We can do that today by generating the automatically generated section and including that in postgresql.conf as an include file. >> 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. The main problem that I've seen described is what I mentioned before: allowing adjusting the postgresql.conf GUC settings by remote users who don't have shell access. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers