Re: classful cidr insertion bug? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: classful cidr insertion bug?
Date
Msg-id 12873.1024284459@sss.pgh.pa.us
Whole thread Raw
In response to classful cidr insertion bug?  (Paul Schultz <pschultz@pschultz.com>)
List pgsql-bugs
Paul Schultz <pschultz@pschultz.com> writes:
> For the cidr data type it says an insertion missing the subnet bits should
> be handled like legacy classful networks.

No, it says:

: The format for specifying classless networks is x.x.x.x/y where x.x.x.x
: is the network and y is the number of bits in the netmask. If y is
: omitted, it is calculated using assumptions from the older classful
: numbering system, except that it will be at least large enough to
: include all of the octets written in the input.

Note the last phrase.

> ie if I insert just
> '172.16.0.0' it should be handled as '172.16.0.0/16'.

No, because you wrote four octets.  Observe:

regression=# select '172.16.0.0'::cidr;
     cidr
---------------
 172.16.0.0/32
(1 row)

regression=# select '172.16'::cidr;
     cidr
---------------
 172.16.0.0/16
(1 row)

regression=# select '172'::cidr;
     cidr
--------------
 172.0.0.0/16
(1 row)

The last example is where the old numbering system actually influences
the result.  You can get a wider-than-written netmask from the old
conventions, but not a narrower-than-written netmask.

I don't personally have a lot of allegiance to this setup, but it
was hashed out through discussions among a number of people who use
the inet types heavily.  If you want to propose changing it, I suggest
you go back and read the archives first.  There will be very little
interest in any complaints that don't include arguments demolishing
the older discussion.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Paul Schultz
Date:
Subject: classful cidr insertion bug?
Next
From: Karel Zak
Date:
Subject: Re: to_date bug