On 30.03.22 18:17, Jacob Champion wrote:
>> Also, if someone ever
>> wants to change how those backend data types work, we then have to check
>> a bunch of other code as well.
>>
>> I think we should be using inet_ntop()/inet_pton() directly here. We
>> can throw substitute implementations into libpgport if necessary, that's
>> not so difficult.
> Is this request satisfied by the implementation of pg_inet_pton() in
> patch 0003? If not, what needs to change?
Why add a (failry complicated) pg_inet_pton() when a perfectly
reasonable inet_pton() exists?
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.
