On Tue, Jun 11, 2002 at 09:26:36AM +1000, Martijn van Oosterhout wrote: > On Mon, Jun 10, 2002 at 08:48:22AM -0500, Steve Langasek wrote: > > My principal objection to this talk of automatically scanning for > > available database engines is that it ignores the fact that SQL servers > > are *servers*, that is, there's a client-server architecture here which > > doesn't require the database engine to be installed on the local host. > > In fact, at work we have centralized database servers that we connect to > > from a number of other machines, so any configuration tool that lets me > > choose from a list of locally-installed database engines is worse than > > useless to me. > Why not simply make a package called pgsql-remote or some such that asks for > the configuration(s) of the remote server(s) and then add them to the > list... And install a separate instance of this package for each postgres server you'll be connecting to? And then you still have to tell that package all the information about your database server, and also take manual action when the server disappears. So what purpose does this package serve, again? The package database is not intended for inventory of remote services. Using it for inventory of /local/ services may meet the needs of a certain subset of users, but if your goal is to provide automatic reconfiguration of middleware applications whenever a database server disappears, I argue that this solution really won't cut it; and as a user, I'd rather have a good interface that allows me to quickly specify my exact settings with a minimum of fuss, rather than being forced to work around an interface that I know isn't going to meet my needs in the end anyway. Steve Langasek postmodern programmer
Attachment:
pgplpWjC0QJjA.pgp
Description: PGP signature