On 12/12/2025 13:41, Daniel Gustafsson wrote:
On Wed, Dec 3, 2025 at 1:57 AM Heikki Linnakangas <[email protected]> wrote:
Maybe. I'm not a big fan of magic-file-exist configurations
Me neither. (I especially don't like the idea of ignoring a
certificate+key setting that a user has taken the time to put into a
config.)
+1
I wonder if the way forward is to do both? Heikki has a good point that when
working with pg_hosts.conf it should be clear from just that file what the
final config will be, and in the previous version that wasn't the case since
the ssl_snimode GUC set operation modes. At the same time, Jacob has a point
that overriding configuration just because pg_hosts exists isn't transparent.
Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can perhaps
fix both complaints? If the GUC is on, pg_hosts - and only pg_hosts - is used
for configuring secrets. By using the * fallback and no_sni rule in pg_hosts
all variations of configs can be achieved. If the GUC is off, then the regular
SSL GUCs are used and pg_host is never considered (and thus SNI is not
possible).
Such a GUC wouldn't make the patch all that much different from what it is
right now. What do you think about that middleground proposal?
I like that.
Instead of a boolean GUC, it could perhaps be a path to the pg_hosts
file. I haven't thought this through but somehow it feels more natural
to me than a "read this file or not" setting.
- Heikki
