> On 3 Dec 2025, at 10:57, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> Sorry for jumping in so late.
Not at all, thanks for looking!
> Do we need the GUC? It feels a little confusing that a GUC affects how the settings in the pg_hosts.conf are
interepreted.It'd be nice if you could open pg_hosts.conf in an editor, and see at one glance everything that affects
this.
I added the GUC for two reasons; as a way to opt-out of this feature if it's
something that the admin doesn't want; and as a way to set the SNI mode. There
are currently the two modes of STRICT and DEFAULT which affects how incoming
connections are handled. The first motivation might be unfounded, and the
second one could be encoded in a pg_hosts configuration though implicitly
rather than explicitly.
Having all the details in pg_hosts.conf is appealing, no disagreement there,
but it does pose some challenges in the interaction with the postgresql.conf
GUCS (more later).
> I propose that there is no GUC. In 'pg_hosts.conf', you can specify a wildcard '*' host that matches anything. You
canalso specify a "no sni" line which matches connections with no SNI specified. (Or something along those lines, I
didn'tthink too hard about all the interactions).
So basically reserving a hostname,"no_sni" or something, which indicates that
it's for non sslsni connections? That should work, with the parsing rule that
there can only be one in the file.
> Should we support wildcards like "*.example.com* too?
I have that on my if-it-gets-committed TODO but I kept it out of the initial
proposal to keep complexity down and goalposts in sight.
> For backwards-compatibility, if you specify a certificate and key in postgresql.conf, they are treated the same as if
youhad a "*" line in pg_hosts.conf.
That's a bit trickier though, since the cert/key have a default boot_val so
they will always be set to something unless the user enables ssl=on and at the
same time uncomments ssl_cert_file/ssl_key_file and set them to '' before
proceeding to add configuration in pg_hosts.conf. This is pretty unintuitive I
think. unintuitive. This backwards comatibility is one of the reasons I kept
the postgresl.conf values for the default context config.
I really want to make it possible for anyone who don't want SNI to keep using
postgresql.conf and get the exact behavior they've always had. Do you agree
with that design goal?
--
Daniel Gustafsson
