Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> We have an RESET command which "returns parameter to its default
>> setting". But what this means is "return it to the value set in current
>> the postgresql.conf, if overriden therein from its default value". So it
>> would be useful to have a column that meant "if I run the RESET command
>> it would return me to this value".
>
>> The boot value is only interesting when the "source" column of
>> pg_settings is "default". In all other cases it is a misleading value,
>> AFAICS. It would be accurate in sessions that have not run SET, or have
>> just issued RESET ALL, but we have no way of knowing whether that is the
>> case or not.
>
> Right, this is why I was complaining that the view should expose the
> reset_val. Greg's opinion that only boot_val is needed seems to be
> focused entirely on DBAs or tools for manipulating postgresql.conf ---
> the only reason you'd want to know boot_val is to know "what will happen
> if I remove this setting from postgresql.conf?". For ordinary users
> boot_val is useless information, but reset_val could be interesting.
If both are interesting to different audiences, perhaps we should be
exposing both as separate columns?
>> I would suggest we either alter pg_settings so that we display value
>> *only* when source=default (set NULL otherwise) or we do some extra work
>> to derive what the setting would be if we ran RESET. The latter would be
>> preferred approach.
>
> Trying to make one column serve both masters sounds hopelessly confusing
> to me; it would essentially make it useless for *both* sets of users,
> because neither would know whether the value they're seeing is the one
> they need.
It sounds like you are making the case for what I write above? Having
one column named reset_val and one named boot_val should work, no?
//Magnus