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

Re: Parsing config files in a directory

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing config files in a directory
Date: 2009-10-27 18:10:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2009-10-27 at 13:21 -0400, Tom Lane wrote:
> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> > ... One file per GUC is certainly never going to fly though, it's 
> > been hard enough getting people to accept going from one file to more than 
> > one.
> One thing that concerns me a bit about the lack of consensus on that
> is what will happen if different config-adjustment tools adopt different
> philosophies.  If Dimitri writes a tool that drops settings into per-GUC
> files, and you write one that puts them all in persistent.conf, and
> somebody tries to use both those tools, no good will come of it.
> If we forgot about the config-dir idea and just had one file that was
> meant to be hacked by automated tools, the problem would go away.
> However I suspect that that proposal won't fly, so we ought to think
> about providing some guidance to tools writers about what to do.
> Is there any consensus on how multiple config files actually get used
> over in the Apache/etc world?

Apache has an include functionality that supports wildcards etc... so I
can do:

include "conf/*.conf"

And it just parses them.

Joshua D. Drake

> 			regards, tom lane


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-27 18:31:38
Subject: Re: Delete cascade with three levels bug ?
Previous:From: Robert HaasDate: 2009-10-27 18:06:10
Subject: Re: Parsing config files in a directory

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