On Thu, Oct 9, 2025 at 11:09 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Agreed. (My proposal doesn't advocate for "regular" breakage.)
I understand that, but you mentioned a few different settings ...
which could hypothetically turn into changing the default for 1 of
them every year or two.
> > When there's not agreement on
> > what to change, leaving things unchanged is often the best answer,
>
> I think that's how we get into situations like "everyone hates
> sslmode=require but no one will change it." I'm looking to add a tool
> to make agreement easier in the first place.
That's a fair goal, but I'm not sure that I agree that the tool you're
proposing actually has that effect.
> (Maybe there's a better tool than a configuration file? But I'd like
> to see what a file looks like, because I'm not familiar with any other
> network client that requires you to put every setting into the URI you
> use to contact the server. If you know of one please tell me so I can
> study it.)
That's a fair complaint, but on the other hand, specifying the use or
non-use of TLS in the URI is completely normal. What's abnormal about
our system is that (1) we've got all of these extra levels that don't
exist for, say, HTTP and (2) our syntax is quite verbose.
> I prefer simplicity, too, but environment variables for libpq mean
> "this is a trusted setting that you should prefer to the default, even
> if it's worse". That's not a good fit for the security-related
> settings I'm concerned with changing.
Can you expand on this thought? I don't think I understand. What makes
the environment variables "trusted values that you should prefer to
the default" rather than just "values that we want to use in this
context"?
--
Robert Haas
EDB: http://www.enterprisedb.com
