Re: Parsing config files in a directory

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
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 01:55:57
Message-ID: alpine.GSO.2.01.0910262125091.5457@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 26 Oct 2009, Greg Stark wrote:

> When scanning postgresql.conf.d we should follow the Apache/Debian
> standard of scanning only files which match a single simple hard-coded
> template. I think the convention is basically the regexp
> ^[0-9a-zA-Z-]*.conf$. It's important that it exclude typical backup file
> conventions like foo~ or foo.bak and lock file conventions like .#foo.
> There's no need for this to be configurable and I think that would be
> actively harmful.

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?

That also seems to be the theme of the rest of your comments about how to
reorganize the postgresql.conf file. Your comments about what should and
shouldn't be configurable presumes it's OK for your priorities and what
you like to be enforced as policy on everyone. Whether or not I agree
with you, I object to the idea of dictating in this area because it just
encourages argument. The goal here is to add flexibility and ways people
can choose to work with the configuration, not to replace what's being
done now outright with an approach everyone must adopt.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-27 03:07:01 Re: per-tablespace random_page_cost/seq_page_cost
Previous Message Christophe Pettus 2009-10-27 01:35:13 Re: Proposal: String key space for advisory locks