Thoughts on a "global" client configuration?

Hi all,

I want to move towards a world where we have sslmode=verify-full by
default. (And maybe gssencmode=disabled, for that matter.) But
changing defaults is risky for established users.

I'm exploring the idea of a global configuration for libpq --
/etc/libpqrc, if you will -- that contains all of our connection
options and lets people override our decisions. So new users and
established users don't have to agree on what's best for their use
cases, and we can make improvements without fearing that we've locked
some subset of users into their "last version" of Postgres because
they can't upgrade.

I started on a proof of concept and very quickly hit a fork. Do I
1) introduce a completely new config file, or
2) adapt pg_service.conf to this use case?

If you're interested in that proof of concept, I'd like to know which
option you'd like to see first. Some thoughts on each are in the
appendix below, if you've got time, but a quick straw-poll response is
helpful too.

Thanks!
--Jacob

= Appendix: Design Thoughts =

I wanted my PoC to show the following:
- a two-tier approach, so that administrators can set system-wide
defaults in /etc and users can set user-wide overrides for those
defaults in their home directory
- backwards and forwards compatibility (we don't ever break old
libpqs, but new libpqs can add new options safely)

That last part is why I initially preferred option (1). I didn't want
to have to figure out the cross-compatibility implications of adapting
pg_service.conf. I thought we could use installation-specific
/etc/postgresql/<version>/libpqrc files and have them be completely
separate from the longstanding service concept.

Unfortunately that has at least one design mistake, which is that the
user-tier config file can't have a version-specific prefix. So I
either put the version into the name (gross), or else I have to solve
cross-compatibility anyway.

If I adapt pg_service.conf, I get the tier system for free. But I
would still have to invent some sort of forwards compatibility
mechanism, and my ideas so far involve adding non-INI syntax to the
beginning of the file, where it would be ignored by existing versions.
It puts us closer to ssh_config territory. Not sure how well that
would go over; there are other projects parsing this.