On Mon, Jun 6, 2022 at 12:02 PM Tom Lane <t...@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
