Re: Second proposal: what to do about INET/CIDR

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> 3. We will add explicit functions cidr(inet) and inet(cidr) to force
>> the data type to one or the other style, thus allowing selection
>> of either display style. Note that cidr(inet) will raise an error
>> if given something with nonzeroes to the right of the netmask.

> Not sure if using functions that look like a cast to control output format
> is a good idea. The conversion inet => cidr seems most naturally left
> with the network() function. The other conversion is not well-defined.
> (You could define it in several reasonable ways, but that still doesn't
> make it "well".)

Good point: cidr() is exactly the same as network() under my proposal,
so we don't need a separate function for that.

While inet() and host() as proposed may be morally impure, they're no
worse than date->timestamp and similar conversions that we have in
abundance. I do not agree that they are ill-defined --- the spec
I wrote seems perfectly clear.

Would you be happier if inet() and host() were defined to produce
textual representations --- respectively "w.x.y.z/n" and "w.x.y.z"
rather than actual INET values? That seems like it'd still solve
the demand for being able to extract these specific representations,
without opening up the quagmire of whether these values are legitimate
INET values.

regards, tom lane