Re: How about a psql backslash command to show GUCs?

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: How about a psql backslash command to show GUCs?
Дата
Msg-id 9439380b-a81f-c910-f527-db4d470b026b@postgresql.org
обсуждение исходный текст
Ответ на Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Следующее
От: Markus Wanner
Дата:
Сообщение: Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]