Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan wrote:
> Mark Kirkwood wrote:
>> Do you need name, value pairs? I was thinking that something like:
>> # Postgres Cluster Registration
>> #
>> /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 :-)  ).



In response to

pgsql-hackers by date

Next:From: Michael FuhrDate: 2006-03-01 03:19:04
Subject: Uninstall script errors
Previous:From: Christopher Kings-LynneDate: 2006-03-01 02:01:22
Subject: Re: bug in 7.3.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group