On Wed, 2013-08-07 at 23:24 -0700, Chris Travers wrote:
> On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So the obvious question today is whether this isn't
> duplicative of the
> range datatype stuff. IOW, why wouldn't we be better off to
> invent
> inetrange and call it good?
INET allows a mask, and so doesn't offer an obvious total order.
Interestingly, a mask is somewhat like a range, so perhaps we could use
a range type that considers a mask to be an alternate representation of
a range. I thought about that briefly, but it seemed more likely to lead
to confusion or backwards-compatibility problems.
If we just had an IP(v4|v6) type with no mask and a total order, adding
a range type would be trivial.
> actually this misses the one area where ip4r is really helpful and
> that is GiST support. If you want to have an exclusion constraint
> which specifies that no two cidr blocks in a table can contain
> eachother, you can do this easily with ip4r but it takes a lot of work
> without it.
A lot of work (much of it by Alexander Korotkov) has already gone into
improving range type [sp-]gist indexes. And range types go together well
with exclusion constraints. So, I'm not sure I follow how this is a
reason to use ip4r rather than a range type -- can you clarify?
Regards,
Jeff Davis