On Wed, 2013-08-07 at 23:24 -0700, Chris Travers wrote: > On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
