Re: What is the motivation of include directive and

From: "Takayuki Tsunakawa" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: What is the motivation of include directive and
Date: 2007-01-18 03:05:48
Message-ID: 01b801c73aad$8dbe2330$19527c0a@OPERAO
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: "Andrew Dunstan" <andrew(at)dunslane(dot)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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenji Kawamura 2007-01-18 09:04:52 pg_trigger.tgargs needs detoast
Previous Message markwkm 2007-01-18 02:35:10 Re: ideas for auto-processing patches