Re: Re: postgres - development of inet/cidr
От | Jakub Bartosz Bielecki |
---|---|
Тема | Re: Re: postgres - development of inet/cidr |
Дата | |
Msg-id | Pine.SOL.4.21.0007051410330.1267-100000@elektron.elka.pw.edu.pl обсуждение исходный текст |
Ответ на | Re: Re: postgres - development of inet/cidr (Sevo Stille <sevo@ip23.net>) |
Список | pgsql-hackers |
On Mon, 3 Jul 2000, Sevo Stille wrote: > > This would be proper behaviour for the cidr datatype, which describes a > network. "select '10.0.0.1/27'::cidr='10.0.0.2/27'::cidr;" has to return > true, as both define the same network, the mask putting the 1 vs. 2 > outside the comparison scope. > > On inet, I consider the above broken - going by the documentation, > having a netmask on a inet datatype does not define a network address > but rather supplies additional information on the cidr network the host > as specified by the address is in. Accordingly, it should only truncate > if the comparison casts to cidr. OK. After some inspection in list's archives I found the following statement (http://www.postgresql.org/mhonarc/pgsql-hackers/1998-07): > It does not work that way. /24 is > not a shorthand for specifying a netmask -- in CIDR, it's a "prefix > length". > That means "192.7.34.21/24" is either (a) a syntax error or > (b) equivilent to "192.7.34/24". Everybody seemed to agree with the above opinion at that time. This is obviously _not_ the way that CIDR is handled at this moment. "select '1.2.3.4/24'" returns "1.2.3/24" only because the _output_ routine silently cuts host bits. Input routine stores it exactly as '1.2.3.4/24'. Since IMHO it's wrong I prepared a patch (I'm sending it to pgsql-patch). It fixes the CIDR input routine to zero host bits (ie beyond-prefix bits). Please note that I didn't change the INET input routine. Eventually I had to change a bit comparison functions. To this moment they worked in a CIDR way (didn't compare host bits at all) although they were used by both INET and CIDR. Since CIDR is zero-padded now, whole 32 bits are compared by > = < operators. Subnet operators <<, >> are still the same, don't compare host bits. > The big question is whether comparisons that only work on a cidr data > type (contains/contained) or have a cidr type on one side can safely > cast the inet type to cidr implicitly. For: > "select '10.0.0.1/27'::inet = '10.0.0.2/27'::inet;" FALSE > "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::cidr;" TRUE > "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::inet;" FALSE > "select '10.0.0.1/27'::cidr >> '10.0.0.2/27'::inet;" TRUE OK. > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR Currently it's not an error... There is no way (and no reason) to distinguish between INET and CIDR. Above example is exactly equivalent to:select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE but:select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE > But we need to reach an agreement on the proper > behaviour on greater/smaller comparisons. Should: > > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;" > > be true or false? Casting to cidr prior to comparison would make it > equivalent to "select '10.0.0.0/27'::cidr > '10.0.0.0/27'::cidr;", which > is false, both networks being equal. It should be (and is!) true... Since second argument is really '10.0.0.0/27'.
В списке pgsql-hackers по дате отправления: