Message-ID: <658f846c-04e0-9391-9ae8-fd698c32637f@enterprisedb.com>
Date: Thu, 31 Mar 2022 16:32:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.7.0
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs
Content-Language: en-US
To: Jacob Champion <pchampion@vmware.com>, "daniel@yesql.se"
 <daniel@yesql.se>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Cc: "stark@mit.edu" <stark@mit.edu>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>
References: <20220318.163857.1357392368287571138.horikyota.ntt@gmail.com>
 <20220322.133202.1699013732440256188.horikyota.ntt@gmail.com>
 <5878cc4f261dfac70999be7c10d80e898449e388.camel@vmware.com>
 <20220323.142007.1816604521514641243.horikyota.ntt@gmail.com>
 <2da38935f528904f62dd5846767dc53585d8a309.camel@vmware.com>
 <552429.1648415967@sss.pgh.pa.us>
 <3F1A8748-DEF8-454C-B7ED-F536CCF7F115@yesql.se>
 <5EA8D400-9705-463C-B30F-E7A78EE5C8FB@yesql.se>
 <27dd89aa5bd8fac8fdfdbd33dd460422bcb77d6b.camel@vmware.com>
 <b2f8b8e9-1c9a-57b2-0c8f-1f3c7fbdb5e2@enterprisedb.com>
 <26dd7e4b482832323e38ba6f08e3651b5c2c5817.camel@vmware.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <26dd7e4b482832323e38ba6f08e3651b5c2c5817.camel@vmware.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/658f846c-04e0-9391-9ae8-fd698c32637f%40enterprisedb.com>
Precedence: bulk

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.