Re: Thoughts on a "global" client configuration?

On 2025-10-08 We 10:39 AM, Robert Haas wrote:
> 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.
>

There's a lot to this POV, and it's made worse by the unattractiveness
of both of Jacob's options.

If we set the default at verify-full (that would be my vote), someone
can undo that for a particular installation by setting PGSSLMODE=prefer
globally on their system, without our inventing a new config file / section.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com