On 27 January 2018 at 04:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > Emre Hasegeli <e...@hasegeli.com> writes: > >> port.h declares inet_net_ntop and we always compile our own from > >> port/inet_net_ntop.c . > > > There is another copy of it under backend/utils/adt/inet_cidr_ntop.c. > > The code looks different but does 90% the same thing. Their naming > > and usage is confusing. > > > I recently needed to format IP addresses as DNS PTR records in the > > database, and got annoyed by having no functions that outputs IPv6 > > addresses in easily parseable format like > > 0000:0000:0000:0000:0000:0000:0000:0000. I was going to send a patch > > to unify those C functions and add another SQL function to get > > addresses in such format. Is this a good plan? Where should those C > > functions be on the tree if they are not port of anything anymore? > > Almost certainly, the thing to do is absorb updated code from bind, > not roll our own.
Definitely. I asked because I didn't see any comments explaining why we had it and why we built it even when the local system has support for it. I noticed because I was building an extension in C++ (yeah, fun) and it breaks because <inet/arpa.h>'s definition of inet_net_ntop is annotated with _THROW , which expands to throw() when building in c++. But this makes the prototype incompatible with the one we (re)declare in port.h without _THROW and causes #include "postgres.h" to fail. Sure, I can add a hack to c.h to define _THROW as a no-op when not on glibc and all that, assuming I get far enough with this extension to bother. But it made me ask why we have this duplication in the first place, hence this post. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
