On 31.03.22 20:15, Jacob Champion wrote:
> 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...
I have committed this.
I have removed the inet header refactoring that you had. That wasn't
necessary, since pg_inet_net_ntop() can use the normal AF_INET*
constants. The PGSQL_AF_INET* constants are only for the internal
storage of the inet/cidr types.
I have added a configure test for inet_pton(). We can check in the
build farm if it turns out to be necessary.