Thread: classful cidr insertion bug?

I'm running into an issue that contradicts how pgsql should behave
according to the documentation.  Running 7.2.1 .deb package.

For the cidr data type it says an insertion missing the subnet bits should
be handled like legacy classful networks.  ie if I insert just
'172.16.0.0' it should be handled as '172.16.0.0/16'.  I'm seeing it get
inserted as '172.16.0.0/32'.

If i insert using for example '172.16' it works and inserts as a /16, so
does classful insertion only work when inputting with an abbreviated
network (and why the choice to have it restricted like that)?  The data
being stored is essentially a selective parsing of an  entire BGP table
from a Cisco router, so legacy class a/b/c space with  8/16/24 bit
netmasks respectively show up without the prefix length bits.


niara=# \d prefixes
                                     Table "prefixes"
  Column   |          Type          |                      Modifiers
-----------+------------------------+-----------------------------------------------------
 prefix    | cidr                   |
 aspath    | character varying(200) |
 origin_as | integer                |
 id        | integer                | not null default
nextval('"prefixes_id_seq"'::text)
Unique keys: prefixes_id_key

niara=# insert into prefixes values ('129.10.0.0', '10913 1239 1 i', '1');
INSERT 415033 1
niara=# select prefix from prefixes where prefix = '129.10.0.0';
    prefix
---------------
 129.10.0.0/32
(1 row)



Thanks,

Paul Schultz

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