Re: Why so few built-in range types?

Hi,

I wanted to craft an answer here and Peter nailed it before I could. I
use ip4r in a bunch of different projects and environments, it's doing a
perfect job, it's simple to use and damn efficient.

The ipv6 support is on the way, parts of it are already be in the CVS at
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/ip4r/ip4r/. It's missing
tests mainly IIRC from a chat with its author, a well known PostgreSQL
contributor, Andrew Gierth.

Really, I wouldn't even consider adding gist support for inet and cidr.
Their real future has been sketched by Tom at last developer meeting, at
least what I remember hom saying is that they should eventually get
shipped as extensions now that it's easy to do so, and removed out of
core with some more types in the same bucket.

I could be misremembering which types Tom was talking about, though.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> - ip4 is fixed-length, so it's much faster. (Obviously, this is living
> on borrowed time. Who knows.)
>
> - Conversely, it might be considered a feature that ip4 only stores IPv4
> addresses.
>
> - ip4 really only stores a single address, not a netmask, not sometimes
> a netmask, or sometimes a range, or sometimes a network and an address,
> or whatever. That really seems like the most common use case, and no
> matter what you do with the other types, some stupid netmask will appear
> in your output when you least expect it.
>
> - Integrates with ip4r, which has GiST support.
>
> - Some old-school internet gurus worked out why inet and cidr have to
> behave the way they do, which no one else understands, and no one dares
> to discuss, whereas ip4/ip4r are simple and appear to be built for
> practical use.
>
> Really, it's all about worse is better.

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