Re: location of the configuration files

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: mlw <pgsql(at)mohawksoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: location of the configuration files
Date: 2003-02-11 18:55:08
Message-ID: 1044989708.12931.44.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2003-02-11 at 13:44, mlw wrote:
> The debate on the configuration file sparked a memory of an old patch I
> submitted in 7.1 days.
>
> One of the things I do not like about PostgreSQL is, IMHO, is a
> backwards configuration process. Rather than specify a data directory,
> the administrator should specify a database configuration file. Within
> the configuration file is the location and names of the data directory
> and other information. Most admins want a central location for this
> information.
>
> One of the things that is frustrating to me, is to have to hunt down
> where the data directory is so that I can administrate a DB. It can be
> anywhere, in any directory on any volume. If you had, say, a
> /usr/local/pgsql/admin, then you could have mydb.conf which could then
> be checked in to CVS. A standard location for configuration files is a
> more normal process as the location of the data directory is less so. I
> just don't think the PG data directory should not contain configuration
> information.
>
> The original patch allowed a user to specify the location of the
> postgresql.conf file, rather than assuming it lived in $PGDATA
> Also included in that patch, was the ability to specify the location of
> the PGDATA directory as well as the names of the pg_hba.conf and other
> configuration files.
>
> It also allowed the user to use PG as it has always worked, The patch
> was not applied because a better solution was supposedly coming, but
> that was two major revisions ago. I would still like to see this
> functionality. Would anyone else?
>

I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.

Robert Treat

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-11 18:55:29 Re: Changing the default configuration (was Re: [pgsql-advocacy]
Previous Message Matthew T. O'Connor 2003-02-11 18:53:51 Re: Changing the default configuration (was Re: [pgsql-advocacy]