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