Re: Thoughts on a "global" client configuration?

On Mon, Oct 6, 2025 at 2:06 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> I want to move towards a world where we have sslmode=verify-full by
> default. (And maybe gssencmode=disabled, for that matter.) But
> changing defaults is risky for established users.
>
> I'm exploring the idea of a global configuration for libpq --
> /etc/libpqrc, if you will -- that contains all of our connection
> options and lets people override our decisions. So new users and
> established users don't have to agree on what's best for their use
> cases, and we can make improvements without fearing that we've locked
> some subset of users into their "last version" of Postgres because
> they can't upgrade.

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. This is why we tend to want to avoid
behavior-changing GUCs on the server side -- anybody who writes an
extension now has to be prepared for every possible value of each of
those settings, and it's not a lot of fun.

Now, all that said, I'm not sure how serious that class of problems is
in this case. In the case of a client application, even if it's
intended as a general tool that might be used by many people on many
systems, in most cases, the author of that tool probably shouldn't
have strong opinions about what details ought to be in the connection
string vs. what details ought to be taken from a configuration file
somewhere. 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. Maybe that can be avoided with an opt-out, like
ignoresystemdefaults=1 or something, but it's worth noting that our
current service-file system avoids this problem by being strictly
opt-in, and I kind of wonder if we ought to stick with that.

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, but I
don't think anybody thinks that sslmode=prefer is actually a good
default any more. I can imagine votes for disable, verify-full, and
maybe require, but prefer seems obviously silly.

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. Decorating every connection string with
sslmode=none (if the default is verify-full and you're running on a
trusted network) or sslmode=verify-full (if the default is none and
you're not running on a trusted network) feels bad, especially if you
have to type those connection strings by hand with any frequency. I
can't help wondering how much of the resistance in this area
(including mine, FWIW) is subtly influenced by the feeling that it's
going to be really annoying when the default isn't what you want in a
particular case.

But despite that, I still think we should ask ourselves whether it
isn't better to endure a hard compatibility break. Maybe it isn't, and
a config file as you propose is indeed a better option. But it doesn't
solve the problem of deciding what the default ought to be in the
absence of a config file, and it does potentially create some new
problems.

--
Robert Haas
EDB: http://www.enterprisedb.com