----- Цитат от Tom Lane (tgl@sss.pgh.pa.us), на 02.12.2011 в 05:21 ----- <br /><br />> Robert Haas writes: <br
/>>>On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost wrote: <br />>>> I don't have any particular care
aboutif cidr has indexing support or <br />>>> not. I'm certainly not *against* it, except insofar as it
encourages<br />>>> use of a data type that really could probably be better (by being more <br />>>>
likeip4r..). <br />> <br />>> Not that you're biased or anything! :-p <br />> <br />> IIRC, a lot of the
basicbehavior of the inet/cidr types was designed by <br />> Paul Vixie (though he's not to blame for their I/O
presentation).<br />> So I'm inclined to doubt that they're as broken as Stephen claims. <br />> <br />>
regards,tom lane <br /><br /><br />I have looked at ip4r README file and my use of the extension. According to <br
/>theREADME, the main reasons for ip4r to exist are: <br /><br />1. No index support for buildin datatypes. <br />2.
Theyare variable width datatypes, because inet/cidr supports IPv6. <br />3. Semantic overloading - no random ranges,
youcould combine IP addr and <br />netmask in inet datatype. <br /><br />What I have found in my experience is that the
semanticsof inet/cidr is what <br />you need in order to model IP networks - interfaces, addresses, routing tables, <br
/>bgpsessions, LIR databases etc. In this regard the main semantic shortcommings <br />of ip4r datatype are: <br /><br
/>1.It could not represent address asignments. For example: <br />ip4r('10.0.0.1/24') is invalid. You sould represent
itwith two ip4r fields - ip4r('10.0.0.1') <br />for the address and ip4r('10.0.0.0/24') for the net. Using build-in
datatypesit <br />could be represented as inet('10.0.0.1/24') <br />2. You could have ip4r random ranges that could not
exestsin the IP network stack of <br />any device. Eg. you could not configure route as 10.0.0.2-10.0.0.6 <br />3. No
IPv6support. <br /><br />So, from my viewpoint the "semantic overloading" of inet type is what you want because <br
/>itrepresents the semantics of IP networks. <br /><br />Best regards <br /><br />-- <br />Luben Karavelov
