scott.marlowe wrote:

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

Than to try to figure out what someone entered when they ran ./configure 
Why do you think PGDATA would be set for root?

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.  
It isn't conformity for conformitys sake. It is following an established practice, like driving on the same side of the road or stopping at red lights.

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.
You are confusing the default location of a file with the ability to use the file. The default I have proposed all along was to use the existing practice of keeping everything in the $PGDATA directory.

The change I wish to make to the code allows this to be changed. Most admins want configuration and data separate. Most admins do not want to use symlinks because they are dangerous in a production environment.

I would rather have a simpler solution sooner than a perfect solution never.

Reply via email to