Re: Thoughts on the location of configuration files
От | teg@redhat.com (Trond Eivind Glomsrød) |
---|---|
Тема | Re: Thoughts on the location of configuration files |
Дата | |
Msg-id | xuyofkmhw6f.fsf@halden.devel.redhat.com обсуждение исходный текст |
Ответ на | Thoughts on the location of configuration files (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Thoughts on the location of configuration files
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > 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. I like this, but I'd prefer to have "-C" point to a specific configuration file. -- Trond Eivind Glomsrød Red Hat, Inc.
В списке pgsql-hackers по дате отправления: