From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Thoughts on the location of configuration files |
Date: | 2001-12-18 22:24:43 |
Message-ID: | Pine.LNX.4.30.0112181903390.637-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
After reading through the strong opinions about the location of the
configuration files in the current and in previous threads, I must concede
that despite the best intentions, the current "everything in one place"
system is obviously not addressing the needs of the user. So while we're
at it we might as well consider more sweeping changes to bring the
system in line with the "expected" or "standard" behaviour.
Consider the following points:
1. Most users will probably only run one server -- especially new users.
2. Most users will expect configuration files somewhere under =~ /etc/ --
including new users.
3. To run more than one server, special knowledge and configuration is
required anyway.
Therefore, a wired-in configuration file location near /etc would be
helpful or at least indifferent for most users.
I suggest that we wire-in the location of the configuration files into the
binaries as ${sysconfdir} as determined by configure. This would default
to /usr/local/pgsql/etc, so the "everything in one place" system is still
somewhat preserved for those that care. For the confused, we could for a
while install into the data directory files named "postgresql.conf",
"pg_hba.conf", etc. that only contain text like "This file is now to be
found at @sysconfdir@ by popular demand."
Furthermore, I suggest that we wire-in the default location of the data
files as ${localstatedir} as determined by configure. This would default
to /usr/local/pgsql/var, which is not quite the same as the customary
/usr/local/pgsql/data but it doesn't matter because with both "initdb" and
"postmaster" defaulting to this directory and the configuration files
elsewhere you don't really need to know except on few occasions. Having
this default would also save me a lot of typing during development. ;-)
Surely we can also add a -C option to override the sysconfdir just as -D
overrides localstatedir. Those that refuse to convert can also set -C
equal to -D and have the old setup. Or the user can only specify -C to
point to the former -D and use the proposed 'datadir' parameter to find
the data area.
But I find a wired-in configuration file location better than having to
use -C everytime you want a "standard" setup because this way we force
users to have consistent setups.
What does this mean for multiple-server setups? Basically you add a -C to
each invocation or you replace -D by -C as explained above. Or if you
want to share the configuration file you only need to add the right -p
option to each invocation. This probably means someone will need to
change their scripts but as we hear they don't like them anyway. Someone
that currently relies on a -D being sufficient will at least get a clean
failure when the ports conflict.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-12-18 22:24:54 | Re: Explicit config patch 7.2B4 |
Previous Message | Peter Eisentraut | 2001-12-18 22:23:42 | Re: [PATCHES] Problem compiling postgres sql --with-tcl |