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
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 |