Re: Explicit configuration file

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, mlw <markw(at)mohawksoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit configuration file
Date: 2001-12-12 20:40:49
Message-ID: 20011212144049.B1461@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 11, 2001 at 10:56:27PM -0500, Bruce Momjian wrote:
>
> My issue is, should we add yet another configuration flag to an already
> flag-heavy command and let people use symlinks for special cases, or
> should we add the flag. I guess the question is whether the option will
> be used by enough people that the extra flag is worth the added
> complexity.

I can tell you that the Debian (and probably RedHat) packaged binaries
would use this switch: It already installs pg_ident.conf, pg_hba.conf,
and postgresql.conf in /etc/postgresql, and puts symlinks into the
PGDATA dor pointing _back_ there, to keep the server happy. I'd forsee
the symlinks just going away.

>
> There is added complexity. Every flag is evaluated by users to
> determine if the flag is of any use to them, even if they don't use it.

Most users never look at _any_ of the flags. Most users who _compile there
own_ read the man page and evaluate the flags, I agree.

> 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.

Seems that's what's actually ben proposed, but in a backwards compatible
way.

Ross

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-12-12 21:08:20 Re: Intermediate report for AIX 5L port
Previous Message Brian Hirt 2001-12-12 20:38:24 Re: ACK table corrupted, unique index violated.