----- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 02.12.2011 в 05:21 -----
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost <sfr...@snowman.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
