Re: pg_config, pg_service.conf, postgresql.conf .... - Mailing list pgsql-hackers
From | Mark Woodward |
---|---|
Subject | Re: pg_config, pg_service.conf, postgresql.conf .... |
Date | |
Msg-id | 16474.24.91.171.78.1140538498.squirrel@mail.mohawksoft.com Whole thread Raw |
In response to | Re: pg_config, pg_service.conf, postgresql.conf .... (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: pg_config, pg_service.conf, postgresql.conf ....
Re: pg_config, pg_service.conf, postgresql.conf .... Re: pg_config, pg_service.conf, postgresql.conf .... Re: pg_config, pg_service.conf, postgresql.conf .... |
List | pgsql-hackers |
> Mark Woodward wrote: >> The pg_config program needs to display more information, specifically >> where the location of pg_service.conf would reside. > > pg_config --sysconfdir Hmm, that doesn't show up with pg_config --help. markw@outland:~$ pg_config --sysconfdir pg_config: invalid argument: --sysconfdir Try "pg_config --help" for more information > >> Also, I know I've been harping on this for years (literally), but >> since the PosgteSQL programs already have the notion that there is >> some static directory for which to locate files (pg_service.conf), >> couldn't we also use this directory to include pg_hba.conf, >> pg_ident.conf, and perhaps even postgresql.conf? > > Considering that pg_service.conf is a client configuration file and the > others are server configuration files, I don't think there is a causal > relationship between putting them one place or another, independent of > the individual merit of placing them in particular spot. I'm not sure > that sentence makes sense. Well, here's the thinking involved: pg_service.conf may currently be considered a "client side" utility, but it need not only be considered that. One of my difficulties with PostgreSQL is that there is no "standardized" location for where everything is located, i.e. self documenting. If you know that "/usr/local/pgsql/etc/pg_service.conf" will contain a list of services, that is really awesome. That you can use these services in libpq is utterly fantastic, from a development point of view. IMHO that is how ALL access to the database should be documented, with the "dbname," port, etc. offered in the administrators guide as a we to debug the services file. Now, from an administrators point of view, say you have to manage over 1000 machines, (This is not unlikely in a Yahoo or other service provider), how do you know where the physical databases reside on each of these machines? OK, maybe you document it somewhere, but we all know that the docs never get updated reliably. Even if you standardize, standards change over years, and some of these machines last for years. Allowing pg_service.conf to contain information about where physcial databases reside on the server is HUGE. This may be helpful to some who are willing to retrofit, but I'm think more as a "moving forward" point of view. OK, maybe pg_service.conf is not the right place for this, and that maybe a valid argument, but the mechanics involved would be a great asset to the admin. Perhaps pg_servers.conf?
pgsql-hackers by date: