Message-ID: <e733621c-2737-4887-8ba8-9c33a7107247@iki.fi>
Date: Wed, 17 Dec 2025 11:06:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Serverside SNI support in libpq
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Daniel Gustafsson <daniel@yesql.se>,
 Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Dewei Dai <daidewei1970@163.com>,
 "li.evan.chao" <li.evan.chao@gmail.com>,
 Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>,
 Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se>
 <F585452A-1F69-4658-A7E8-D1273AC663ED@yesql.se>
 <aLT9xVsTVp0j3zWy@paquier.xyz>
 <80F4F8F4-8E4F-4B6F-866B-D837057C1192@yesql.se>
 <D9F6F14D-FCB1-48B5-9CBC-AE89FA0AEF4C@yesql.se>
 <CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
 <0C53C316-C24E-4307-807B-D825CA3F7254@yesql.se>
 <DD77A37A-BFCA-4819-A029-1A41E2443D8E@gmail.com>
 <378D83FA-338C-4EA1-BC60-397BE08D0F01@yesql.se>
 <2025112617144938459246@163.com>
 <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se>
 <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
 <5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se>
 <f621264b-26a6-4b7a-8982-3820b7d6d397@iki.fi>
 <CAGECzQTWH-bzHcdPo=i09TL_P6_HBBNEkBmr+rpN_J9zVfR2Fw@mail.gmail.com>
 <785C0B88-7068-4576-AF55-251D06CEC112@yesql.se>
 <CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@mail.gmail.com>
 <FB2759EB-C8DB-49FA-800F-7010C65EB8DF@yesql.se>
 <4b9923d6-65f3-46d5-8360-462f8381fbee@iki.fi>
Content-Language: en-US
In-Reply-To: <4b9923d6-65f3-46d5-8360-462f8381fbee@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/e733621c-2737-4887-8ba8-9c33a7107247%40iki.fi>
Precedence: bulk

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