On Tue, 2008-09-16 at 00:10 -0400, Greg Smith wrote: > Attached is an updated and separate version of my patch exposing the > internal GUC boot_val as default_val, which failed to attach itself to the > already committed changes to the pg_settings view. > > Brief reminder of what it does: > > postgres=# select name,setting,default_val from pg_settings where > name='shared_buffers'; > name | setting | default_val > ----------------+---------+------------- > shared_buffers | 4096 | 1024 > > General justification for this change with a longer example is at > http://archives.postgresql.org/pgsql-hackers/2008-09/msg00233.php > > Based on feedback the first time around, I updated the documentation for > this column to read "Default value assumed at server startup if the > parameter is not otherwise set". > > Would only take a quick search/replace of the patch to change > "default_val" to something else if there are still any objections there. > "boot_val" is another candidate name, I feel that would make the purpose > of the column less obvious to users of pg_settings even if it is more > correct. I'm really more concerned about the feature than exactly what > it's named though. I didn't bother to expose the reset_val since I can't > think of any obvious use cases for wanting to know it.
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. 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. So column name boot_val seems most correct currently, but not very useful. If we can make the changes above, then I'd stick with default_val. I like the concept very much though so please don't take my words as opposition. *This* patch should not be applied, but a similar one could and should be. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
