"Matthew N. Dodd" <winter@jurai.net> writes:
> Plus, it would enable me to use my existing data without reloading.
> (ignoring the fact that 6.4 will probably require this.)
6.4 definitely will require a database reload, so as long as the
external representations are compatible this isn't a good argument
for a separate /32 type.
The space issue might be something to think about. But I'm inclined
to think that we should build in IPv6 support from the get-go, rather
than have to add it later. We ought to try to be ahead of the curve
not behind it. So it's gonna be more than 4 bytes/entry anyway.
Would it make sense to use atttypmod to distinguish several different
subtypes of CIDR? "4 bytes", "4 bytes + mask", "6 bytes", "6 bytes
+ mask" seem like interesting possibilities.
regards, tom lane
