From: "Andrew Dunstan" <andrew@dunslane.net>
> Meeting FHS requirements is no bad thing, though. And the ability to
> include a common configuration set in multiple instances is surely
> useful to a number of people. After all, you aren't forced to use
these
> facilities - I typically don't.
Thank you, Andrew-san.
What I want to know is a more concreet thing.
How useful are those facilities to what kind of users in what cases?
Is there a reason why users in the real world positively use those
facilities?
If I want to develop an add-on tool that manipulates PostgreSQL
settings even when PostgreSQL is stopped, should that tool support the
environments where include directive is used and config files are
placed outside the data directory? If the need for include directive
and flexible config file placement is very low or vague, I thought I
could say "this tool does not support those environments".
Are any facilities (functions) provided in PostgreSQL that external
tool developers can use to read/write config files? Suppose a user
created a database instance manually, with the config files as
follows:
[$PGDATA/postgresql.conf]
...
max_connections=10
include '/some_dir/some.conf'
include '/other_dir/other.conf'
[/some_dir/some.conf]
...
max_connections=50
[/other_dir/other.conf]
...
max_connections=100
If an external tool wants to determine the current value of
max_connections or modify the setting, what should the tool do?
Should the tool parse and write out the files by itself?