Re: [PATCH] Accept IP addresses in server certificate SANs - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PATCH] Accept IP addresses in server certificate SANs
Date
Msg-id bf8ab04e2fcd8a8fdb2a49229e3bc8a952248eb7.camel@vmware.com
Whole thread Raw
In response to Re: [PATCH] Accept IP addresses in server certificate SANs  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: [PATCH] Accept IP addresses in server certificate SANs  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Thu, 2022-03-31 at 16:32 +0200, Peter Eisentraut wrote:
> Why add a (failry complicated) pg_inet_pton() when a perfectly
> reasonable inet_pton() exists?

I think it was mostly just that inet_aton() and pg_inet_net_ntop() both
had ports, and I figured I might as well port the other one since we
already had the implementation. (I don't have a good intuition yet for
the community's preference for port vs dependency.)

> I would get rid of all that refactoring and just have your code call
> inet_pton()/inet_ntop() directly.
> 
> If you're worried about portability, and you don't want to go through
> the effort of proving libpgport substitutes, just have your code raise
> an error in the "#else" code paths.  We can fill that in later if there
> is demand.

Switched to inet_pton() in v12, with no #if/else for now. I think this
should work with Winsock as-is; let's see if the bot agrees...

Thanks,
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Next
From: Peter Geoghegan
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations