On Thu, Jan 22, 2015 at 3:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Johnston <david.g.johnston@gmail.com> writes: > On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Is that a requirement, and if so why? Because this proposal doesn't >> guarantee any such knowledge AFAICS.
> The proposal provides for SQL access to all possible sources of variable > value setting and, ideally, a means of ordering them in priority order, so > that a search for TimeZone would return two records, one for > postgresql.auto.conf and one for postgresql.conf - which are numbered 1 and > 2 respectively - so that in looking at that result if the > postgresql.auto.conf entry were to be removed the user would know that what > the value is in postgresql.conf that would become active. Furthermore, if > postgresql.conf has a setting AND there is a mapping in an #included file > that information would be accessible via SQL as well.
I know what the proposal is. What I am questioning is the use-case that justifies having us build and support all this extra mechanism. How often does anyone need to know what the "next down" variable value would be? And if they do need to know whether a variable is set in postgresql.conf, how often wouldn't they just resort to "grep" instead? (Among other points, grep would succeed at noticing commented-out entries, which this mechanism would not.)
GUC has existed in more or less its current state for about 15 years, and I don't recall a lot of complaints that would be solved by this. Furthermore, given that ALTER SYSTEM was sold to us as more or less obsoleting manual editing of postgresql.conf, I rather doubt that it's changed the basis of discussion all that much.
i doubt we'd actually see many complaints since, like you say, people are likely to just use a different technique. The only thing PostgreSQL itself needs to provide is a master inventory of seen/known settings; the user interface can be left up to other layers (psql, pgadmin, extensions, etc...). It falls into making the system more user friendly. But maybe the answer for those users is that if you setup is so complex this would be helpful you probably need to rethink your setup. Then again, if I only interact with the via SQL at least can issue RESET and know the end result - after a config reload - without having to log into the server and grep the config file - or know what the system defaults are for settings that do not appear explicitly in postgresql.conf; all without having to refer to documentation as well.
I'm doubtful it is going to interest any of the core hackers to put this in place but it at least warrants a couple of passes of brain-storming which can then be memorialized on the Wiki-ToDo.