Re: Adding ip4r to Postgresql core?

On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Tom Lane wrote:
> >> That's been proposed before, and rejected before, on the grounds that
> >> since it doesn't support IPv6 its days are numbered.
>
> > Actually, that's not true.
>
> Ah, my information is obsolete.
>

As a user of ip4r, yes, we use it with ipv6 just fine.

>
> > Quoting from the linked readme file,
> > : IP4R therefore supports six distinct data types:
> > : ip4 - a single IPv4 address
> > : ip4r - an arbitrary range of IPv4 addresses
> > : ip6 - a single IPv6 address
> > : ip6r - an arbitrary range of IPv6 addresses
> > : ipaddress - a single IPv4 or IPv6 address
> > : iprange - an arbitrary range of IPv4 or IPv6 addresses
>
> So the obvious question today is whether this isn't duplicative of the
> range datatype stuff. IOW, why wouldn't we be better off to invent
> inetrange and call it good?
>

actually this misses the one area where ip4r is really helpful and that is
GiST support. If you want to have an exclusion constraint which specifies
that no two cidr blocks in a table can contain eachother, you can do this
easily with ip4r but it takes a lot of work without it. iprange is mostly
helpful in that area.

Our current core data types have better cross-type casting support, but the
lack of GiST support (a commutable overlaps operator for example) is a
really big limitation.

My vote would be to focus on GiST support instead, but otherwise ip4r would
be acceptable to me.

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml