Re: Summary: what to do about INET/CIDR

On Fri, 27 Oct 2000, Tom Lane wrote:

> 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?
_maybe_ cuz this is an invalid address. (an address cannot have all-zeros
or all-ones host part). On other hand, postgres doesn't enforce that in
inet_in, so its inconsistent to enforce it there...

> > 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 ...
Probably cidr_inet should make a copy instead of just "blessing" the
original value?

-alex