Re: Summary: what to do about INET/CIDR

Larry Rosenman <ler@lerctr.org> writes:
> OK, what I really meant was a way to coerce a CIDR entity to INET so 
> that host() can work with a CIDR type to print all 4 octets. 

Hm.  I don't see any really good reason why host() rejects CIDR input
in the first place.  What's wrong with producing the host address
that corresponds to extending the CIDR network address with zeroes?

> Currently you can't coerce a CIDR type to INET. 

Well you can, but it doesn't *do* anything.  One of the peculiarities
of these two types is that the cidr-vs-inet flag is actually stored
in the data value.  The type-system differentiation between CIDR and
INET is a complete no-op for everything except initial entry of a value
(ie, conversion of a text string to CIDR or INET); all the operators
that care (which is darn few ... in fact it looks like host() is the
only one!) look right at the value to see which type they've been given.
So applying a type coercion may make the type system happy, but it
doesn't do a darn thing to the bits, and thus not to the behavior of
subsequent operators either.  I have not yet figured out if that's a
good thing or a bad thing ...
        regards, tom lane