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

Re: Parsing config files in a directory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, 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-28 00:35:37
Message-ID: 603c8f070910271735x2e945200ld6e4f8160f48417@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Oct 27, 2009 at 2:59 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> IME, the use case for multiple Apache configuration files is that
>> there are bits of configuration that support particular modules which
>> packagers want installed only in conjunction with the corresponding
>> modules - it has nothing to do with being able to automate config-file
>> updates, or at least I am not aware that it does.
>
> That sounds like automated config file updates to me. Individual
> modules are being installed and uninstalled and automatically updating
> the configuration to handle the modules.

Well, OK, fair enough.  I guess my point is that there are two things
that you might want:

- multiple config files separated by domain (e.g. this is the config
file for autoexplain, and this one is for vacuum)
- multiple config files separated by how they are updated (e.g. this
config file is only for people with text editors, and this one is for
people using SET PERSISTENT)

The Apache model is definitely the first of these, AFAICS.  The
proposals on this thread mostly seem to be an amalgam of both, which
doesn't strike me as a terribly good idea, but evidently I'm in the
minority.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-10-28 00:50:30
Subject: Re: per-tablespace random_page_cost/seq_page_cost
Previous:From: Christophe PettusDate: 2009-10-27 23:50:11
Subject: Re: Proposal: String key space for advisory locks

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