On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> writes:
> Tom Lane wrote:Ah, my information is obsolete.
>> 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.
As a user of ip4r, yes, we use it with ipv6 just fine.
So the obvious question today is whether this isn't duplicative of the
> 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
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.
