On Mon, Jun 29, 2015 at 11:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Sawada Masahiko <sawada.m...@gmail.com> writes: >> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
