Re: Parsing config files in a directory

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Parsing config files in a directory
Дата
Msg-id alpine.GSO.2.01.0910262125091.5457@westnet.com
обсуждение исходный текст
Ответ на Re: Parsing config files in a directory  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Parsing config files in a directory  (Greg Stark <gsstark@mit.edu>)
Re: Parsing config files in a directory  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@gregsmith.com http://www.gregsmith.com Baltimore, MD


В списке pgsql-hackers по дате отправления:

Предыдущее
От: 노홍찬
Дата:
Сообщение: Re: a question about relkind of RelationData handed over to heap_update function
Следующее
От: Tom Lane
Дата:
Сообщение: Re: per-tablespace random_page_cost/seq_page_cost