From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | emre(at)hasegeli(dot)com, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redefining inet_net_ntop |
Date: | 2018-01-29 01:43:54 |
Message-ID: | CAMsr+YHUtepk=0U=4+QN0SidXDCeoTQuwcYToQBo=-jGycpZJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 January 2018 at 04:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Emre Hasegeli <emre(at)hasegeli(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2018-01-29 02:25:50 | Re: Invalid result from hash_page_items function |
Previous Message | Amit Langote | 2018-01-29 01:08:51 | Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables |