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