From: | mlw <pgsql(at)mohawksoft(dot)com> |
---|---|
To: | Kevin Brown <kevin(at)sysexperts(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Location of the configuration files, round 2 |
Date: | 2003-02-15 06:13:04 |
Message-ID: | 3E4DDA70.7080701@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2003-02-15 07:46:53 | Re: Incremental backup |
Previous Message | Curt Sampson | 2003-02-15 04:44:00 | Re: location of the configuration files |