On Mon, Jun 6, 2022 at 12:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thoughts?
This all seems pretty subjective. As someone who sometimes supports
customers, I usually kind of want the customer to give me all the
settings, just in case something that didn't seem important to them
(or to whoever coded up the \dconfig command) turns out to be
relevant. It's easier to ask once and then look for the information
you need than to go back and forth asking for more data, and I don't
want to have to try to infer things based on what version they are
running or how a certain set of binaries was built.
But if I already know that the configuration on a given system is
basically sane, I probably only care about the parameters with
non-default values, and a computed parameter can't be set, so I guess
it has a default value by definition. So if the charter for this
command is to show only non-default GUCs, then it seems reasonable to
leave these out.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
