Re: Parsing config files in a directory

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 03:16:56
Message-ID: 407d949e0910262016t56872315p89ed0decc1bfbe9e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 26, 2009 at 6:55 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> If the default glob pattern is *.conf, won't all those already be screened
> out?  I can see your point that letting it be adustable will inevitably
> result in some fool one day writing a bad matching pattern that does grab
> backup/lock files.  But is that concern so important that we should limit
> what people who know what they're doing are allowed to do?

Well the file name is a kind of API so if it's not fixed it's less
useful. Modules won't know how to name the files they drop in so
they'll be read. Autotuning packages won't know what characters are
allowed in their filename or how to disable their file or backup files
if they want. Etc.

There's not really any flexibility to be gained in using a different
pattern anyways since the user and other programmers are free to
choose filenames which match the pattern.

This isn't novel territory. Other software like Apache have had config
directories for aeons. And Debian makes extensive use of them for
packages which have other packages providing behaviour changing
addons. I believe the conventions I suggested are the common
conventions used by most -- afaik all -- of these other projects.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-27 03:19:46 Re: Parsing config files in a directory
Previous Message Tom Lane 2009-10-27 03:07:01 Re: per-tablespace random_page_cost/seq_page_cost