Robert Haas <robertmhaas@gmail.com> writes:
> I think part of the problem here, though, is that one can imagine a
> variety of charters that might be useful. A user could want to see the
> parameters that have values in their session that differ from the
> system defaults, or parameters that have values which differ from the
> compiled-in defaults, or parameters that can be changed without a
> restart, or all the pre-computed parameters, or all the parameters
> that contain "vacuum" in the name, or all the query-planner-related
> parameters, or all the parameters on which any privileges have been
> granted. And it's just a judgement call which of those things we ought
> to try to accommodate in the psql syntax and which ones ought to be
> done by writing an ad-hoc query against pg_settings.
Sure. Nonetheless, having decided to introduce this command, we have
to make that judgement call.
psql-ref.sgml currently explains that
If <replaceable class="parameter">pattern</replaceable> is specified,
only parameters whose names match the pattern are listed. Without
a <replaceable class="parameter">pattern</replaceable>, only
parameters that are set to non-default values are listed.
(Use <literal>\dconfig *</literal> to see all parameters.)
so we have the "all of them" and "ones whose names match a pattern"
cases covered. And the definition of the default behavior as
"only ones that are set to non-default values" seems reasonable enough,
but the question is what counts as a "non-default value", or for that
matter what counts as "setting".
I think a reasonable case can be made for excluding "internal" GUCs
on the grounds that (a) they cannot be set, and therefore (b) whatever
value they have might as well be considered the default.
regards, tom lane