Re: How about a psql backslash command to show GUCs? - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: How about a psql backslash command to show GUCs?
Date
Msg-id 9439380b-a81f-c910-f527-db4d470b026b@postgresql.org
Whole thread Raw
In response to Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/11/22 3:12 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 4/9/22 12:27 PM, Tom Lane wrote:
>>> 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.
>>>
>>> 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".
> 
>> Reasonable points. I don't have any objections to this proposal.
> 
> Hearing no further comments, done like that.

Thanks!

I have a usability comment based on my testing.

I ran "\dconfig" and one of the settings that came up was 
"max_connections" which was set to 100, or the default.

I had noticed that "max_connections" was uncommented in my 
postgresql.conf file, which I believe was from the autogenerated 
provided by initdb.

Similarly, min_wal_size/max_wal_size were in the list and set to their 
default values. These were also uncommented in my postgresql.conf from 
the autogeneration.

My question is if we're only going to list out the settings that are 
customized, are we going to:

1. Hide a setting if it matches a default value, even if a user set it 
to be the default value? OR
2. Comment out all of the settings in a generated postgresql.conf file?

Thanks,

Jonathan

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Next
From: Markus Wanner
Date:
Subject: Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]