Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Sunday, January 27, 2013 10:07 AM Robert Haas wrote:
On Sat, Jan 26, 2013 at 6:47 PM, Craig Ringer  wrote:
> On 01/27/2013 01:01 AM, Tom Lane wrote:
>> Robert Haas  writes:
>>> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund  wrote:
>>>>> More people seem to have voted for the single file approach but I still
>>>>> haven't understood why...
>>>> Me neither.  Having an include directory seems good, but I can't think
>>>> why we'd want to clutter it up with a bajillion automatically
>>>> generated files.  One .auto file that gets overwritten at need seems
>>>> way nicer.
>>> IMO an include directory containing just one file is silly.  If we're
>>> going with the single-file approach, let's lose the directory altogether
>>> and just store the file at $PGDATA/postgresql.conf.auto.
>> Wasn't part of the reason for having the config dir to make package
>> managers' lives easier and make it easier to script updates to
>> postgresql.conf? For the use of things like pg_wrapper?
>
>> I think the config dir has value even if a single .auto file is used, so
>> that packages can drop their own config snippets into it. For example,
>> if I installed a packaged extension that had its own postgresql.conf
>> changes or new GUCs, I'd want it to be able to drop that into the
>> configdir, not have to script changes to my postgresql.conf.

> That was my understanding.  But I just work here.

Current implementation of patch is to have directory and single file.
However if user puts other files, it gives LOG: unexpected file found in automatic configuration directory .
As now Craig has explained the usecase for having other files and previously Fujii Masao has also reported similar
usecase, I think it is better to remove the LOG message from code.
Currently the directory is named as auto.conf.d, so if we allow users to place other files, is this name okay
or shall we change it to something like config_dir?

With Regards,
Amit Kapila.