> 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/