Re: Summary: what to do about INET/CIDR

Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> We should have as much error-checking as possible.

Only possible with a much tighter definition of what the intended use
of each type is. For example, you seem to be saying that broadcast
addresses aren't valid inet values, with which I do not agree unless
there is another type that they can be part of.

My inclination is to leave INET with the range of valid values it
currently has, and to let people apply column constraints if they
want to restrict a particular column to, say, valid host addresses,
or valid broadcast addresses, or whatever.

> Broadcast address does _not_ have a netmask, i.e. 10.0.0.255/24
> does not make sense as inet, it should be 10.0.0.255/32

How so? Without a netmask you have no way to know if it's a broadcast
address or not. 10.0.0.255/32 might be a perfectly valid host address
in, say, 10.0/16. But 10.0.0.255/24 is recognizably the broadcast
address for 10.0.0/24 (and not for any other network...)

> (ie. broadcast() function must return a value with /32 mask)

I don't disagree with that part, but that's only because I see
broadcast() as mainly a display convenience. If we had a larger and
more thoroughly worked out set of inet/cidr operators, I'd be inclined
to argue that broadcast('10.0.0.0/24') should yield 10.0.0.255/24 for
computational convenience. Then we'd need to offer a separate function
that would let you strip off the netmask for display purposes (actually
host() would do for that...)

regards, tom lane