Re: pg_getaddrinfo_all() with hintp=NULL

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergey Tatarintsev <s(dot)tatarintsev(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_getaddrinfo_all() with hintp=NULL
Date: 2025-11-13 13:57:52
Message-ID: 45893974-FBC4-4EF5-9900-3565C361F5CA@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 13 Nov 2025, at 01:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:

>> It's still not clear to ne that we should make pg_getaddr_info() mimic the API
>> of getaddrinfo since it's not a thin wrapper over getaddrinfo. The alternative
>> option would be to return EAI_FAIL on a null hint and force the caller to
>> provide an AF_UNSPEC if that is what is indeed asked for.
>
> We already reject null hints (by crashing), and have done for decades.
> I don't think there's anything very wrong with the current code, and I
> don't really see that the proposed patch is an improvement. If
> anything, I'd just add a comment to pg_getaddrinfo_all saying that
> unlike bare getaddrinfo, we require a valid hintp.

That's my thinking as well, unless objected to I will apply the below which use
the same phrasing as the comment on pg_getnameinfo_all.

diff --git a/src/common/ip.c b/src/common/ip.c
index 0e7897a5c8f..71e5934557e 100644
--- a/src/common/ip.c
+++ b/src/common/ip.c
@@ -48,6 +48,9 @@ static int getnameinfo_unix(const struct sockaddr_un *sa, int salen,

/*
* pg_getaddrinfo_all - get address info for Unix, IPv4 and IPv6 sockets
+ *
+ * The API of this routine differs from the standard getaddrinfo() definition
+ * in that it requires a valid hintp, a null pointer is not allowed.
*/
int
pg_getaddrinfo_all(const char *hostname, const char *servname,

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ivan Kovmir 2025-11-13 13:59:23 Comment possible shared memory re-attach failure
Previous Message Alexander Kukushkin 2025-11-13 13:08:54 Re: Issue with logical replication slot during switchover