Re: Thoughts on a "global" client configuration? - Mailing list pgsql-hackers

On Wed, Oct 8, 2025 at 7:39 AM Robert Haas <robertmhaas@gmail.com> wrote:
>

Thanks for the feedback!

> I think the down side of this kind of system is that it makes life
> harder for people who want to write code that works everywhere. You
> have to take into account the possibility that the configuration file
> could be overriding the compiled-in defaults and messing up your
> extension/tool/utility.

There's truth in that, I think, from a support standpoint. It's a knob
which can be used to improve or destroy, and we could probably expect
to see a transition period where some bug reports are closed with "why
did you put that in your configuration?"

I need to put more thought into the interaction with existing
postgresql:// URIs, as well.

> But there are counterexamples, such as our regression
> tests. It seems like those tests are never likely to be stable under
> every possible choice of settings that you might put in that file, and
> eventually somebody who is running a buildfarm machine will end up
> with a file installed that breaks something, and that will be
> annoying.

I think this is already solved. We have PGSYSCONFDIR, which allows
tests to pull configuration from the temporary installation directory
instead (and makes pg_service.conf relocatable for all of our
utilities). Both of my proposed solutions can make use of that.

> Maybe that can be avoided with an opt-out, like
> ignoresystemdefaults=1 or something

An opt-out would be pretty easy to add if needed, and it would align
with clients like OpenSSH (`-F none`) and OpenLDAP (`LDAPNOINIT=1`).
But I'd want to pin down what the use cases are before adding one.

> Because the alternative to what you're describing here is to just
> change the defaults in some new major release, and let the chips fall
> where they may. People will have to adjust, and one way they might do
> that is by using a service file to recover the old defaults. Whether
> that's better or worse than trying to ease the migration with some
> mechanism like the one you propose here is a judgement call,

My vote is "worse", because while everyone seems to agree that
`prefer` is bad, no one seems to agree on what the replacement should
be. So momentum on the list dies quickly. And it's not just sslmode
that's in the crosshairs; even if we somehow got to agreement on a
compatibility break there, the exact same discussion is going to
happen with the next one.

In my opinion, there _is_ no "best for everyone". But we can lower the
cost of a "bad" choice (for less common use cases), to make room to
adjust defaults and make them "best for new users", or "best for the
community", or etc. Distribution packagers could further adjust them
to what's best for their communities, too.

> To be honest, I think part of the problem here has to do with our
> choice of syntax. For HTTP, you just change the URL from http to https
> and it's one extra character.

I think a syntax discussion focuses too much on sslmode in particular,
and not enough on other settings that would also be good to ratchet
forward at some point: min_protocol_version, sslnegotiation,
ssl_min_protocol_version, sslrootcert, etc.

The idea that all of these client configuration options belong inside
our resource locators, as opposed to a file on disk somewhere, is...
peculiar. It's nice that they _can_ be part of the syntax, I guess,
but they shouldn't really _have_ to be.

Thanks,
--Jacob