From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | karavelov(at)mail(dot)bg, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why so few built-in range types? |
Date: | 2011-12-02 00:56:01 |
Message-ID: | 20111202005601.GH24234@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-12-02 01:13:02 | Re: Inlining comparators as a performance optimisation |
Previous Message | Robert Haas | 2011-12-01 23:47:17 | Re: backup_label during crash recovery: do we know how to solve it? |