From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul Schultz <pschultz(at)pschultz(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: classful cidr insertion bug? |
Date: | 2002-06-17 03:27:39 |
Message-ID: | 12873.1024284459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Paul Schultz <pschultz(at)pschultz(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2002-06-17 09:08:32 | Re: to_date bug |
Previous Message | Paul Schultz | 2002-06-17 00:35:22 | classful cidr insertion bug? |