On Fri, Dec 2, 2011 at 3:42 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> - ip4 is fixed-length, so it's much faster. (Obviously, this is living
> on borrowed time. Who knows.)
Fair point.
> - Conversely, it might be considered a feature that ip4 only stores IPv4
> addresses.
True, although this can also be enforced by application logic or a
check constraint quite easily. Of course that is likely not as fast,
going to point #1.
> - 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.
Yes, this is mildly annoying; but at worst it is a defect of inet, not
cidr, which does exactly what I'd expect a cidr type to do.
> - Integrates with ip4r, which has GiST support.
Well, OK, so I want GiST support for cidr. That's where this all started.
> - 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.
Heh, OK, well, that's above my pay grade.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company