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. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers