Thread: Location of the configuration files, round 2

Wow, there's been a lot of discussion on this issue!


While it won't address some of the issues that have been brought up,
there is one very simple thing we can do that will help sysadmins
quite a lot: eliminate the postmaster's use of $PGDATA, and force the
data directory to be specified on the command line.  It's fine if the
shell scripts still use $PGDATA, but the postmaster should not.

The reason is that at least it'll always be possible for
administrators to figure out where the data is by looking at the
output of 'ps'.


While I'd prefer to also see a GUC variable added to the config file
that tells the postmaster where to look for the data, the above will
at least simplify the postmaster's code (since the logic for dealing
with $PGDATA can be eliminated) while eliminating some of the trouble
administrators currently have with it.



-- 
Kevin Brown                          kevin@sysexperts.com

One of the things that I HATE about this discussion is that everyone 
wants to put limits on configurability.

I am an old fashion UNIX guy, capability without enforcing policy! 
Adding an ability is different than enforcing a policy. All I any to do 
is add the capability of configuration in a way that most admins would 
be used to.

If people want an FHS compatible install, I don't care. I want to enable 
it, but it should not be enforced.


Kevin Brown wrote:

>Wow, there's been a lot of discussion on this issue!
>
>
>While it won't address some of the issues that have been brought up,
>there is one very simple thing we can do that will help sysadmins
>quite a lot: eliminate the postmaster's use of $PGDATA, and force the
>data directory to be specified on the command line.  It's fine if the
>shell scripts still use $PGDATA, but the postmaster should not.
>
>The reason is that at least it'll always be possible for
>administrators to figure out where the data is by looking at the
>output of 'ps'.
>
>
>While I'd prefer to also see a GUC variable added to the config file
>that tells the postmaster where to look for the data, the above will
>at least simplify the postmaster's code (since the logic for dealing
>with $PGDATA can be eliminated) while eliminating some of the trouble
>administrators currently have with it.
>
>
>
>  
>

mlw <pgsql@mohawksoft.com> wrote: 

> I am an old fashion UNIX guy, capability without enforcing policy! 
> Adding an ability is different than enforcing a policy. 

You can push this too far, though.  Every capability that
you add still complicates testing and documentation, even if
very difficult to code.  And ultimately you're going to want
it to default or auto-configure in a reasonable way, so most
people aren't even going to look at the additional
capabilities.

> All I any to do is add the capability of configuration in
> a way that most admins would be used to.

Which is an important issue of course.  So you need some 
discussion to establish what the common practices are.