Thoughts on the location of configuration files - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Thoughts on the location of configuration files |
Date | |
Msg-id | Pine.LNX.4.30.0112181903390.637-100000@peter.localdomain Whole thread Raw |
Responses |
Re: Thoughts on the location of configuration files
Re: Thoughts on the location of configuration files Re: Thoughts on the location of configuration files |
List | 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@gmx.net
pgsql-hackers by date: