On Sat, Apr 9, 2022 at 9:27 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> "Jonathan S. Katz" <jk...@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.
David J.
