"Jonathan S. Katz" <jkatz@postgresql.org> writes: > -1, at least for the moment. Sometimes a user doesn't know what they're > looking for coupled with being unaware of what the default value is. If > a setting is set to a default value and that value is the problematic > setting, a user should be able to see that even in a full list.
Sure, but then you do "\dconfig *". With there being several hundred GUCs (and no doubt more coming), I'm not sure that "show me every GUC" is a common use-case at all, let alone so common as to deserve being the default behavior.
I'm for having a default that doesn't mean "show everything".
I'm also wondering whether we can invent GUC namespaces for the different contexts, so I can use a pattern like: context.internal.*
A similar ability for category would be nice but we'd have to invent labels to make it practical.
\dconfig [pattern [mode]]
mode: all, overridden
So mode is overridden if pattern is absent but all if pattern is present, with the ability to specify overridden.
pattern: [[{context.{context label}}|{category.{category label}}.]...]{parameter name pattern}
parameter name pattern: [{two part name prefix}.]{base parameter pattern}
One thing we could perhaps do to reduce confusion is to change the table heading when doing this, say from "List of configuration parameters" to "List of non-default configuration parameters".
I'd be inclined to echo a note after the output table that says that not all configuration parameters are displayed - possibly even providing a count [all - overridden]. The header is likely to be ignored even if it still ends up on screen after scrolling.