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