Re: Thoughts on a "global" client configuration?

On Wed, Oct 15, 2025 at 12:20 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> > - backwards and forwards compatibility (we don't ever break old
> > libpqs, but new libpqs can add new options safely)
>
> It might be worth elaborating exactly how this would be solved.  If I
> look through my dotfiles history, this kind of thing has been a
> perennial problem.  I don't have any specific ideas right now -- other
> than perhaps "ignore unknown parameters", which is surely not without
> problems.  Depending on what we'd settle on here, that might inform
> whether it's feasible to stick this into pg_service.conf or whether it
> needs to be a separate thing.

Good timing. Here's a patchset that experiments with putting it all
into pg_service.conf.

= Roadmap =

Patches 0001-0003 are small tweaks to make my life easier. I can pull
them out separately if there's interest.

0004 implements a defaults section:

  [my-default-section]
  +=defaults
  sslmode=verify-full
  gssencmode=disable

  [other-service]
  ...

0005 implements forwards compatibility by marking specific defaults as
ignorable:

  [default]
  +=defaults
  require_auth=scram-sha-256
  channel_binding=require
  ?incredible_scram_feature=require

0006 implements PGNODEFAULTS to allow our test suites (and anything
else) to turn off the new handling. This prevents a broken
~/.pg_service.conf from interfering with our tests. (A different way
of solving that could be to point PGSERVICE to a blank file. I kind of
liked the "turn it off" switch, though.)

= Thoughts =

I wanted to keep INI compatibility. I found a few clients that run
pg_service.conf through a generic INI parser, which seems like an
entirely reasonable thing to do. Going back to my earlier argument
against environment variables, if we make people use this tool to get
themselves out of a compatibility problem we introduce, and it then
causes other existing parts of the Postgres ecosystem to break, I
wouldn't feel great about that.

(I could see an argument that breaking those clients would make it
obvious that they can't apply the new defaults section correctly. But
our old libpqs won't be able to apply the defaults section either, and
we're presumably not going to accept breaking old libpqs.)

I wanted to avoid stomping on existing service names. I could have
gone the Windows route and generated a GUID or something, but instead
I've allowed the user to choose any name they want for this section.
They then mark it with the (maybe-too-cute?) magic string of
"+=defaults", which
1) will cause earlier libpqs to fail if they accidentally try to
select the section as a service,
2) is INI parseable (the key is "+"), and
3) kind of suggests what the section is meant to do: add these
settings to the defaults.

I've tried to avoid too much unbearable confusion by requiring that a
defaults service be at the top of the file and have its marker first
in the section.

One subtlety that I hadn't considered was how the user and system
files interact with one another. I want user defaults to override
system defaults, if they are in conflict. But user services completely
replace system services of the same name, so the code needs to keep
the two behaviors separate.

An emergent feature popped out of this while I was implementing the
tests. You can now choose a default service, and the effect is that
any settings listed there take precedence over the envvars.
"Superdefaults." This is fragile, though -- setting a different
service gets rid of those rather than merging them -- and I was idly
wondering if that was something that could/should be made into its own
first-class concept.

The ability to ignore specific options was inspired by the ability of
an ssh_config to IgnoreUnknown. Maybe you don't care if a nice-to-have
option is ignored by older libpqs, but you maybe want to fail
immediately if some security-critical option can't be honored (or if
you just made a typo), and I think we should assume the latter. This
feature would let you mark them accordingly.

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?

--Jacob