Обсуждение: Re: [GENERAL] Bug? Netmask of CIDR as TEXT has trailing masklen

nomad@null.net writes:
> The following displays as I would expect:
>     mark=# select netmask('1.1.1.0/24');
>         netmask
>     ---------------
>      255.255.255.0
>     (1 row)

> However the following does not look right:

>     mark=# select netmask('1.1.1.0/24')::text;
>          netmask
>     ------------------
>      255.255.255.0/32
>     (1 row)

> The trailing "/32" should not be there.

Yes, it should be: that is the same as "text(netmask('1.1.1.0/24'))",
and the table of network functions specifically describes text(inet)
as "extract IP address and netmask length as text".  If you only want
the IP address, use host(), or possibly abbrev() which I think follows the
output function's rule of suppressing the netmask when it is full-width.

From a system-wide consistency standpoint, it's rather unfortunate that
inet's default conversion to text type does not behave the same as the
inet output function.  But it's been like that for umpteen years and
the costs of breaking backwards compatibility would outweigh any benefit
of changing it.

            regards, tom lane

On Fri Dec 23, 2016 at 10:15:21AM -0500, Tom Lane wrote:
>
> Yes, it should be: that is the same as "text(netmask('1.1.1.0/24'))",
> and the table of network functions specifically describes text(inet)
> as "extract IP address and netmask length as text".  If you only want
> the IP address, use host(), or possibly abbrev() which I think follows the
> output function's rule of suppressing the netmask when it is full-width.

Ah, I just noticed that the return value of the netmask() function is
of type 'inet' and that is (in my mind) where the actual issue is. A
netmask may have the same underlying form and space requirements as an
internet address or subnet, but it isn't really the same thing.

> From a system-wide consistency standpoint, it's rather unfortunate that
> inet's default conversion to text type does not behave the same as the
> inet output function.  But it's been like that for umpteen years and
> the costs of breaking backwards compatibility would outweigh any benefit
> of changing it.

I can see the consistency issue, but I actually don't have much of an
problem with the fact that 'inet' converts to text as 'addr/mask' by
default.  That at least is still an accurate presentation form. But I
have never been presented with a the concept of a network mask having
its own network mask. That just feels wrong.

Do the same backwards compatibility requirements apply to the result
type of the netmask() function? Perhaps a new 'netmask' type with a
better text conversion is possible?

Mark.
--
Mark Lawrence

nomad@null.net writes:
> Ah, I just noticed that the return value of the netmask() function is
> of type 'inet' and that is (in my mind) where the actual issue is. A
> netmask may have the same underlying form and space requirements as an
> internet address or subnet, but it isn't really the same thing.

Maybe, but we're not going to invent a whole new datatype just to
represent that.  Perhaps you would be happier using the masklen()
function.

            regards, tom lane