Re: Thoughts on a "global" client configuration?

On Wed, Oct 29, 2025 at 7:20 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> After studying this a bit more and reading your account, I'm now
> coming over to the side that a libpq defaults configuration file
> should be separate from the existing services file mechanism.

I think I agree, for all the reasons you cited. I'll work on a second draft.

> Conversely, a libpq defaults file
> is more the concern of the OS admin, and per-user configuration will
> be less common.

I'm not sure I agree with this. Unlike with services, an admin might
have good reason to pull the defaults up system-wide, _and_ a user
might want to further override them for clients under their control,
rather than messing with services or asking for root privileges. I
view it mostly as a matter of scope.

> We could still have the defaults file and the services file use the
> same format and parser, if that helps.

I'd actually like to strengthen it a bit, if we can afford to. The
service parser is lax in a bunch of ways, and stricter than necessary
in others (no spaces allowed for formatting?).

> On the question of ignoring unknown settings, or related compatibility
> questions.  The core use case is altering the compiled-in defaults and
> giving users a way to effectively revert that.  So ideally in most
> cases it won't get used at all.

Sure, but see my earlier response to Robert on ecosystem effects. If
this feature is a break-glass solution for a minority of users, we had
better make sure it gets them out of the emergency situation without
breaking more things.

> Hypothetically, you might want to change the default of
> sslnegotiation someday, but if not all libpq versions in the field
> support that setting, then it's probably also too soon to change the
> default.  So perhaps this problem regulates itself.

Maybe... but if the community were to reach a consensus that a default
change is needed sooner (for any setting), I would hate for there to
be a mechanical reason that we couldn't. Let that be a matter of
maintainer policy rather than parser compatibility.

> Also, generally,
> you will only have one libpq version per system, so supporting many
> versions concurrently might not be needed.

For Deb-alikes, yes, but I don't think that's true for our RPMs.

> In fact, do we even need a per-user version of this?  Maybe take the
> OpenSSL approach: There is only a global config file, and you can
> supply a different one with an environment variable.  That should
> satisfy those who want different defaults for their local psql use.

I didn't like this idea at first due to the lack of merge capability,
but I'm slowly coming around to it. Maybe no one really needs a
two-tier solution.

Thanks,
--Jacob