Re: pg_config, pg_service.conf, postgresql.conf ....

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Mark Woodward <pgsql(at)mohawksoft(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Date: 2006-03-01 02:18:21
Message-ID: 4405046D.5080801@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Fuhr 2006-03-01 03:19:04 Uninstall script errors
Previous Message Christopher Kings-Lynne 2006-03-01 02:01:22 Re: bug in 7.3.2