----- Цитат от 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('') is invalid. You sould represent it with two ip4r fields - 
for the address and ip4r('') for the net. Using build-in datatypes it
could be represented as inet('')
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
3. No IPv6 support.

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

Best regards

Luben Karavelov

Reply via email to