Re: Bug? Netmask of CIDR as TEXT has trailing masklen

From: nomad(at)null(dot)net
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Bug? Netmask of CIDR as TEXT has trailing masklen
Date: 2016-12-23 16:31:23
Message-ID: 20161223163123.GA15179@rekudos.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Richards 2016-12-23 16:35:26 explain analyze showed improved results without changes, why?
Previous Message Alessandro Baggi 2016-12-23 16:03:28 Re: [OT] Postgresql and PHP