Re: Why so few built-in range types?

----- Цитат от Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us), на 02.12.2011 в 05:21 -----

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>>> I don't have any particular care about if cidr has indexing support or
>>> not. I'm certainly not *against* it, except insofar as it encourages
>>> use of a data type that really could probably be better (by being more
>>> like ip4r..).
>
>> Not that you're biased or anything! :-p
>
> IIRC, a lot of the basic behavior of the inet/cidr types was designed by
> Paul Vixie (though he's not to blame for their I/O presentation).
> So I'm inclined to doubt that they're as broken as Stephen claims.
>
> regards, tom lane

I have looked at ip4r README file and my use of the extension. According to
the README, the main reasons for ip4r to exist are:

1. No index support for buildin datatypes.
2. They are variable width datatypes, because inet/cidr supports IPv6.
3. Semantic overloading - no random ranges, you could combine IP addr and
netmask in inet datatype.

What I have found in my experience is that the semantics of inet/cidr is what
you need in order to model IP networks - interfaces, addresses, routing tables,
bgp sessions, LIR databases etc. In this regard the main semantic shortcommings
of ip4r datatype are:

1. It could not represent address asignments. For example:
ip4r('10.0.0.1/24') is invalid. You sould represent it with two ip4r fields - ip4r('10.0.0.1')
for the address and ip4r('10.0.0.0/24') for the net. Using build-in datatypes it
could be represented as inet('10.0.0.1/24')
2. You could have ip4r random ranges that could not exests in the IP network stack of
any device. Eg. you could not configure route as 10.0.0.2-10.0.0.6
3. No IPv6 support.

So, from my viewpoint the "semantic overloading" of inet type is what you want because
it represents the semantics of IP networks.

Best regards

--
Luben Karavelov