Re: location of the configuration files

On Thu, 13 Feb 2003, mlw wrote:

> 
> 
> Christopher Browne wrote:
> 
> >In the last exciting episode, cjs@cynic.net (Curt Sampson) wrote:
> >
> >>On Wed, 12 Feb 2003, Peter Bierman wrote:
> >>
> >>>What do you gain by having the postmaster config and the database
> >>>data live in different locations?
> >>>
> >>You can then standardize a location for the configuration files.
> >>
> >>Everybody has room in /etc for another 10K of data. Where you have
> >>room for something that might potentially be a half terrabyte of
> >>data, and is not infrequently several gigabytes or more, is pretty
> >>system-depenendent.
> >
> >Ah, but this has two notable problems:
> >
> >1.  It assumes that there is "a location" for "the configuration files
> >    for /the single database instance./"
> >
> >    If I have a second database instance, that may conflict.
> >
> >2.  It assumes I have write access to /etc
> >
> >    If I'm a Plain Old User, as opposed to root, I may only have
> >    read-only access to /etc.
> >
> >These conditions have both been known to occur...
> >  
> >
> These are not issues at all. You could put the configuration file 
> anywhere, just as you can for any UNIX service.
> 
> postmaster --config=/home/myhome/mydb.conf
> 
> I deal with a number of PG databases on a number of sites, and it is a 
> real pain in the ass to get to a PG box and hunt around for data 
> directory so as to be able to administer the system. What's really 
> annoying is when you have to find the data directory when someone else 
> set up the system.

Really?  I would think it's easier to do this:

su - pgsuper
cd $PGDATA
pwd

Than to try to figure out what someone entered when they ran ./configure 
--config=...

> Configuring postgresql via a configuration file which specifies all the 
> data, i.e. data directory, name of other configuration files, etc. is 
> the right way to do it. Even if you have reasons against it, even if you 
> think it is a bad idea, a bad standard is almost always a better 
> solution than an arcane work of perfection.

Wrong, I strongly disagree with this sentament.  Conformity to standards 
for simple conformity's sake is as wrong as sticking to the old way 
because it's what we're all comfy with.  

> Personally, however, I think the configuration issue is a no-brainer and 
> I am amazed that people are balking. EVERY other service on a UNIX box 
> is configured in this way, why not do it this way in PostgreSQL? The 
> patch I submitted allowed the configuration to work as it currently 
> does, but allowed for the more standard configuration file methodology.

If I do a .tar.gz install of apache, I get /usr/local/apache/conf, which 
is not the standard way you're listing.  If I install openldap from 
.tar.gz, I get a /usr/local/etc/openldap directory, close, but still not 
the same.  The fact is, it's the packagers that put things into /etc and 
whatnot, and I can see the postgresql RPMs or debs or whatever having that 
as the default, but for custom built software, NOTHING that I know of 
builds from source and uses /etc without a switch to tell it to, just like 
postgresql can do now.

> I just don't understand what the resistance is, it makes no sense.

I agree, but from the other side of the fence.