Re: Thoughts on a "global" client configuration?

On Thu, Oct 9, 2025 at 4:21 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> This again tries to collapse the problem down to sslmode. Look at
> gssencmode, sslnegotiation, sslrootcert: all things which IMHO do not
> belong in the query string of a URI. We've put connection settings and
> application settings at the same level, and to me, that's the abnormal
> thing about our system. (Similar problem to the _pq_.* protocol option
> debates, actually.)

That's a really interesting observation. I've always found it a bit
odd that we put things like sslca and sslrootcert into the connection
string, so I think you have a point, here. Not sure I agree about
sslnegotiation or gssencmode, though -- those seem more like sslmode,
which I would argue does belong in the connection string.

> Sure: In the context of this thread, I want the configuration file to
> be able to act as a pressure release valve for admins who absolutely
> cannot follow us forward into verify-full by default, by allowing them
> to return to the previous behavior. But setting a new environment
> variable isn't guaranteed to return to the previous behavior, because
> it's reasonable for applications to defer to trusted envvars if
> they're set. (Think `${PGSSLMODE:-verify-full}`.)

I think this is aiming at quite a narrow target.

> The worst-case persona, in my mind, is a new sysadmin who's panicking
> because of a libpq5 upgrade in production on Debian, say maybe through
> an indirect package dependency, and something has started failing that
> wasn't caught in testing. Downgrading means losing whatever package
> brought in the dependency, and they're definitely not equipped to
> audit all their code to make sure that PGSSLMODE=prefer isn't going to
> do something horrible. I want to give that sysadmin a safe way out.

I would argue that this is a sign that calling every version libpq5 no
matter how much we've changed the behavior is completely insane. This
scenario gets a whole lot better if installing a new release of
PostgreSQL that behaves differently doesn't magically change the
behavior of any existing releases that are already installed.

At the risk of repeating myself, I also think that we need to consider
the flip side of this scenario: some system administrator who thinks
they know better throws something into a system-wide configuration
file and breaks things for, say, PostgreSQL developers running the
regression tests, or applications running on the machine that assume a
certain system-wide configuration that in reality need not prevail
everywhere. I sometimes worry too much about non-problems at times,
and this might be one of those times, so it would be good to hear from
more people, but I think we need to be convinced not only that this
proposal has enough upside to be worth pursuing but also that the
downsides won't be too painful.

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