Re: Add default_val to pg_settings
От | Tom Lane |
---|---|
Тема | Re: Add default_val to pg_settings |
Дата | |
Msg-id | 4760.1222345999@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add default_val to pg_settings (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Add default_val to pg_settings
|
Список | pgsql-hackers |
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. > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: