On 17/12/2025 11:03, Heikki Linnakangas wrote:
> On 12/12/2025 13:41, Daniel Gustafsson wrote:
>> 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.
I was thinking that the boolean GUC would be called something like
"read_pg_hosts_file = on / off", which feels unnatural. But thinking
about this more, if the GUC is called something like "enable_sni = on /
off", that feels much better, and I like that more than my suggestion of
specifying the path to the pg_hosts file.
- Heikki
