Re: Thoughts on a "global" client configuration?

On 16.10.25 01:19, Jacob Champion wrote:
> I'm not sure if all this is better than an architecture where the
> defaults and services are contained in different files. Since the
> syntax and behavior of the two types of sections is explicitly
> different, maybe combining them would be unnecessarily confusing for
> users?

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.

First, just to have a clear naming. If someone wants to know where to
set the default SSL version, an answer like
/etc/postgresql/pg_service.conf doesn't make much sense.

The two mechanisms have different audiences. Currently, a
pg_service.conf entry is necessarily made in conjunction with some
application program using it. I suspect a system-wide pg_service.conf
file doesn't actually get much use. Conversely, a libpq defaults file
is more the concern of the OS admin, and per-user configuration will
be less common.

The hierarchy of the settings from different sources becomes very
complicated, as you already alluded to. A user-configured service
will completely override a system-configured service, which makes some
sense, but libpq defaults should merge on a per-parameter level.
Also, I would expect that environment variables override libpq
defaults, but with the services, it's the other way around.
Consolidating all of that into one mechanism would be very confusing.
If we have separate mechanisms with a clear hierarchy, like 0)
compiled-in, 1) defaults file, 2) environment vars, 3) services, 4)
explicit parameters, then it's clearer.

And then you could also have different policies in the two kinds of
files, like ignoring unknown settings in the defaults file, if that
kind of thing were desired.

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

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. And normally you won't change the
defaults of settings that were only recently introduced. So you might
want to change the default of sslmode, but all versions in the field
support that. 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. Also, generally,
you will only have one libpq version per system, so supporting many
versions concurrently might not be needed.

To that end, it would be important not to get this facility confused
with a user preferences facility, or a per-remote-host configuration
(like ssh_config). Maybe people want that too, but it should be
designed differently.

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.
But for most other uses, the relevant user is some service account,
for which dot files are always awkward anyway.