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 по дате отправления: