On Wed, Sep 22, 2010 at 9:01 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> I can't imagine trying to configure Bacula using ini file format - the mind
> just boggles. Frankly, I'd rather stick with our current config format than
> change to something as inadequate as ini file format.
Perhaps we need to define a little better what information we think we
might eventually need to represent in the config file. With one
exception, nobody has suggested anything that would actually require
hierarchical structure. The exception is defining the policy for
deciding when a commit has been sufficiently acknowledged by an
adequate quorum of standbys, and it seems to me that doing that in its
full generality is going to require not so much a hierarchical
structure as a small programming language. The efforts so far have
centered around reducing the use cases that $AUTHOR cares about to a
set of GUCs which would satisfy that person's needs, but not
necessarily everyone else's needs. I think efforts to encode
arbitrary algorithms using configuration settings are doomed to
failure, so I'm unimpressed by the argument that we should design the
config file to support our attempts to do so. For everything else, no
one has suggested that we need anything more complex than,
essentially, a group of GUCs per server. So we could do:
[server]
guc=value
or
server.guc=value
...or something else. Designing this to support:
server.hypothesis.experimental.unproven.imaginary.what-in-the-world-could-this-possibly-be
= 42
...seems pretty speculative at this point, unless someone can imagine
what we'd want it for.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company