On Fri, Dec 2, 2011 at 3:42 AM, Peter Eisentraut <pete...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to