Re: Thoughts on a "global" client configuration?
От | Chao Li |
---|---|
Тема | Re: Thoughts on a "global" client configuration? |
Дата | |
Msg-id | 79F20BF8-E2D6-411C-9A6B-99CEE0379F9D@gmail.com обсуждение исходный текст |
Ответ на | Re: Thoughts on a "global" client configuration? (Jacob Champion <jacob.champion@enterprisedb.com>) |
Список | pgsql-hackers |
> On Oct 16, 2025, at 07:19, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > I wanted to avoid stomping on existing service names. I could have > gone the Windows route and generated a GUID or something, but instead > I've allowed the user to choose any name they want for this section. > They then mark it with the (maybe-too-cute?) magic string of > "+=defaults", which > 1) will cause earlier libpqs to fail if they accidentally try to > select the section as a service, > 2) is INI parseable (the key is "+"), and > 3) kind of suggests what the section is meant to do: add these > settings to the defaults. I don’t have a strong option on the direction, so I was watching the discussion and waiting for the patch. Before reviewing the patch, I have a comment to the design. I am not convinced that the “=+defaults” approach is the best design. 1) Not self-documenting. Without documentation, hard to guess what it is exactly for. 2) Actually “default = true” will also causes earlier libpq to fail, but “default = true” is easier to understand. Something I want to clarify are: * If there are multiple default sections present, how will them be handled? * Do we want to support specifying a default section? For example: ``` [test_default] default = true X = Y … [prod_default] default = true X = Z … [service_a] default = test_default [service_b] default = prod_default ``` Best regards, Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: