> 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(at)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
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?
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2006-02-21 16:15:56|
|Subject: Re: pg_config, pg_service.conf, postgresql.conf ....|
|Previous:||From: Tom Lane||Date: 2006-02-21 15:17:02|
|Subject: Re: pg_config, pg_service.conf, postgresql.conf .... |