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).
In response to
pgsql-hackers by date
|Next:||From: Christopher Kings-Lynne||Date: 2006-03-01 02:01:22|
|Subject: Re: bug in 7.3.2|
|Previous:||From: Mark Woodward||Date: 2006-03-01 01:03:05|
|Subject: Re: pg_config, pg_service.conf, postgresql.conf ....|