Re: Explicit configuration file

From: mlw <markw(at)mohawksoft(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit configuration file
Date: 2001-12-12 16:13:37
Message-ID: 3C178231.FA15B887@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:

> I wonder if we should go one step further. Should we be specifying the
> config file on the command line _rather_ than the data directory. We
> could then specify the data directory location in the config file. That
> seems like the direction we should be headed in, though I am not sure it
> is worth the added headache of the switch.

That is what the patch I submitted does.

In the postgresql.conf file, you can specify where the data directory
is, as well as the pg_hba.conf file exists.

The purpose I had in mind was to allow sharing of pg_hba.conf files and
keep configuration separate from data.

One huge problem I have with symlinks is an admin has to "notice" that
two files in two separate directories, possibly on two different
volumes, are the same file, so it is very likely the ramifications of
editing one file are not obvious.

If, in the database configuration file, pghbaconfig points to
"/etc/pg_hba.conf" it is likely, that the global significance of the
file is obvious.

(Note: I don't nessisarily think "pghbaconfig" nor "pgdatadir" are the
best names for the parameters, but I couldn't think of anything else at
the time.)

Symlinks are a perilous UNIX construct, yes, they make some things, that
would otherwise be a horrible kludge, elegant, but they are also no
substitute for a properly configurable application.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brian Hirt 2001-12-12 17:13:42 ACK table corrupted, unique index violated.
Previous Message Brian Hirt 2001-12-12 15:10:07 ACK table corrupted, unique index violated.