Skip site navigation (1) Skip section navigation (2)

Re: Why so few built-in range types?

From: karavelov(at)mail(dot)bg
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why so few built-in range types?
Date: 2011-12-02 14:23:32
Message-ID: fdc2c272f384aa941cd189973cce9cc2.mailbg@beta.mail.bg (view raw or flat)
Thread:
Lists: pgsql-hackers
----- Цитат от 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

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-12-02 15:05:15
Subject: Re: review: CHECK FUNCTION statement
Previous:From: Robert HaasDate: 2011-12-02 13:57:48
Subject: Re: Inlining comparators as a performance optimisation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group