| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Jacob Champion <pchampion(at)vmware(dot)com>, "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "stark(at)mit(dot)edu" <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "horikyota(dot)ntt(at)gmail(dot)com" <horikyota(dot)ntt(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Accept IP addresses in server certificate SANs |
| Date: | 2022-03-31 14:32:27 |
| Message-ID: | 658f846c-04e0-9391-9ae8-fd698c32637f@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2022-03-31 14:35:30 | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
| Previous Message | Robert Haas | 2022-03-31 14:31:32 | Re: Commitfest Update |