Re: Thoughts on a "global" client configuration?

On Wed, Oct 15, 2025 at 7:16 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> 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.

Yeah, I can talk a bit about my personal flip-flopping there.
- I started with a "default=true" marker, and decided I didn't want to
camp on something that could plausibly be a connection string option.
- I switched to "!default=true!" and decided it was ugly.
- Once I realized the subtlety of the merge vs replace behavior
compared to services, I tried "+=", to try to evoke the merge idea.

*If* we decide to support a configuration file, *and* we decide to
choose the section+marker approach, I think the choice of marker would
be a good thing to bikeshed. Something fairly self-documenting would
be ideal. But the first two "ifs" are far from decided.

> Something I want to clarify are:
>
> * If there are multiple default sections present, how will them be handled?

This patchset rejects that (if I've implemented it correctly). One
default section only.

> * Do we want to support specifying a default section?

This is similar to Isaac's service nesting proposal. I'm not excited
about mixing the defaults section behavior with the service sections,
because I think it would confuse users about which options take
precedence when.

At the moment, defaults defer to envvars, which defer to services. But
a "default selection" feature doesn't "look" like it works that way,
at least not to my eyes. And I'm not sure if users would ever want the
ability to switch defaults per service (as opposed to just putting
those options into the service). Isaac's nested services seem like a
better way to go if organization and deduplication is the goal.

Thanks!
--Jacob