Re: classful cidr insertion bug?
| От | Tom Lane |
|---|---|
| Тема | Re: classful cidr insertion bug? |
| Дата | |
| Msg-id | 12873.1024284459@sss.pgh.pa.us обсуждение |
| Ответ на | classful cidr insertion bug? (Paul Schultz <pschultz@pschultz.com>) |
| Список | 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 по дате отправления: