On Mon, Jun 29, 2015 at 11:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sawada Masahiko <sawada.mshk@gmail.com> writes:
>> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> So let me make a radical proposal that both gets rid of the portability
>>> problem and, arguably, makes the view more useful than it is today.
>>> I think we should define the view as showing, not what was in the config
>>> file(s) at the last SIGHUP, but what is in the files *now*. That means
>>> you could use it to validate edits before you attempt to apply them,
>>> rather than having to pull the trigger and then ask if it worked. And yet
>>> it would remain just about as useful as it is now for post-mortem checks
>>> when a SIGHUP didn't do what you expected.
>
>> You meant that we parse each GUC parameter in configration file, and
>> then pass changeVal=false to set_config_option whenever
>> pg_file_settings is refered.
>> So this view would be used for checking whether currently
>> configuration file is applied successfully or not, right?
>
> Well, it would check whether the current contents of the file could be
> applied successfully.
>
>> The such a feature would be also good, but the main purpose of
>> pg_file_settings was to resolve where each GUC parameter came from,
>> especially in case of using ALTER SYSTEM command.
>> I'm not sure that it would be adequate for our originally purpose.
>
> I'm not following. Surely pg_settings itself is enough to tell you
> where the currently-applied GUC value came from.
>
Ah yes, it would be enough to accomplish originally purpose.
In order to see current contents of each configuration file, we need
read them whenever pg_file_settings is referred, right?
Regards,
--
Sawada Masahiko
