From: "Andrew Dunstan" <[EMAIL PROTECTED]> > 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? ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly