Re: Serverside SNI support in libpq - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Serverside SNI support in libpq
Date
Msg-id DB146660-EED0-4926-B32A-1EF38EDFF4E9@yesql.se
Whole thread
In response to Re: Serverside SNI support in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Serverside SNI support in libpq
List pgsql-hackers
> On 4 May 2026, at 21:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> It seems quite odd to me that load_host(), which in fact returns
> HostsFileLoadResult codes, is declared to return int.  That seems
> to have been done because HostsFileLoadResult wasn't declared in
> the same header, but there is no visible reason why it shouldn't be.
> Any objection to the attached fixup?

At some point during the development of the patch there was a reason (which I
cannot remember right now) for the declaration being in hba.h, but I clearly
missed moving it when that no longrer applied.  No objections to the patch,
thanks!

> As a side matter, "load_host" seems like a remarkably generic name
> that conveys little about what it actually does, and to the extent
> that it does convey anything the implication is wrong: it returns
> (potentially) info about multiple hosts not just one.  Can't we do
> better?

It's following the naming convention of load_hba() which reads pg_hba.conf, and
load_ident() which reads pg_ident.conf - thus load_hosts() for the function
that reads pg_hosts.conf.  Perhaps load_pg_hosts_conf() or load_hosts_config()
would convey more meaning?

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: [PATCH] Clean up property graph error messages
Next
From: Sami Imseih
Date:
Subject: Re: Track skipped tables during autovacuum and autoanalyze