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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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