Andrew Dunstan wrote:
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74 5432
Clearly other fields are possible (like ALIAS for the names you were
using, and OPTS for extra arguments).
This sort of layout is easily readable (more easily readable for those
of us used to standard UNIX config files) and simply parsable too.
I am a Unix guy through and through, but its config files have pained me
many times over the years. Not least because of lack of consistency.
This sort of layout fails miserably if there are optional fields. Look
at the handsprings we had to turn to put CIDR addresses into
pg_hba.conf. And not without debate.
I don't much like ini style configs either.
These days, for Perl apps I generally make the config file a perl hash,
which can be as deeply structured as you like. The great advantage is
that you get parsing for free. For other apps I'm mildly inclined to
YAML or XML configs. All of these might be verbose, but they have 2 huge
advantages: they can adapt to structure, and they are somewhat
self-documenting. I am currently wrestling with an app that does
horrible things because its config needs to be tree structured and is
instead flat (and also utterly unreadable).
I agree that if there are real requirements that demand (more than one)
optional parameter(s), and tree structures, then by all means let's use
a format that can handle them properly.
However, it would be a shame to dive off into something complex if
something simple would do. From what I've seen on this thread so far,
the simple conf file is a good fit (unless I've missed something -
always possible unfortunately :-) ).
regards
Mark
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
