Re: Why so few built-in range types?

----- Цитат от Stephen Frost (sfrost(at)snowman(dot)net), на 01.12.2011 в 15:56 -----

> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> > Erm, isn't there a contrib type that already does all that for you..?
>> > ip4r or whatever?  Just saying, if you're looking for that capability..
>>
>> Oh, huh, good to know. Still, I'm not sure why you need to load a
>> separate type to get this... there's no reason why the built-in CIDR
>> type couldn't support it.
>
> The semantics of that type aren't what people actually want and there's
> been push-back about changing it due to backwards compatibility, etc.
> That's my recollection of the situation, anyway. I'm sure there's all
> kinds of fun talk in the archives about it.
>

I have reached one or two times to use build-in inet/cidr types but the lack of
indexing support for "contains op" was stopping me - i have used ip4r extension.

I do not think that adding index support to a datatype classifies as semantic
change that will break backward compatibility.

Best regards
--
Luben Karavelov

On Thu, Dec 1, 2011 at 9:12 AM, <karavelov(at)mail(dot)bg> wrote:
> I do not think that adding index support to a datatype classifies as
> semantic
> change that will break backward compatibility.

Me neither. The ip4r type also supports ranges that aren't on
CIDR-block boundaries, which probably isn't something that makes sense
to incorporate into cidr. But not everyone needs that, and some
people might also need support for ipv6 CIDR blocks, which ip4r
doesn't support. So I don't necessarily see the existence of ip4r as
a reason why cidr shouldn't have better indexing support.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Me neither. The ip4r type also supports ranges that aren't on
> CIDR-block boundaries, which probably isn't something that makes sense
> to incorporate into cidr. But not everyone needs that, and some
> people might also need support for ipv6 CIDR blocks, which ip4r
> doesn't support. So I don't necessarily see the existence of ip4r as
> a reason why cidr shouldn't have better indexing support.

Seems I wasn't clear. The semantic changes were why ip4r was *created*
(instead of just using cidr..). The fact that it's got index support is
independent from that (though, in my view, shows that people who
actually care about this data type use ip4r and don't use cidr, or we'd
hear much more complaining..).

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..).

Thanks,

Stephen

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

The ip4r extension's main use case is range lookups. You get an ip and
want to know what range it's in: GiST indexing makes that operation
damn fast, and the ip4r datatype is quite flexible about what a range
is. Apparently core types are solving other problems, that I never had
to solve myself, so I never used them.

Installing ip4r in a database is routine operation, I could accept
having that by default without blinking now.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support