Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
