Re: Re: postgres - development of inet/cidr

"D'Arcy J.M. Cain" wrote:
>
> Thus spake Jakub Bartosz Bielecki
> > 1. all functions which return text (host, network etc) should
> > return pascal-like ASCII string not C-like ASCIIZ
> > example:
> > select host('10.0.0.1')='10.0.0.1'; -- this returns false!

Which it should not. In a text-to-text comparison, both have to be
equal.

> > 2. inet comparison routines (and thus operators) work in a strange way
> > if I set netmask length to a non-default value (other than 32).
> > example:
> > select '10.0.0.1/27'::inet='10.0.0.2/27'::inet; -- returns true
> > I guess that this behaviour is different from described in manual.

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.

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
"select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR

it looks sane, IMHO. 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. But we have at least three possible
comparisons of host to network - besides comparing net to net, the host
might be compared to the the base or top address of the network. That
situation can only be resolved doing explicit casts, so throwing an
error in these cases is IMHO indicated.

Sevo

--
sevo(at)ip23(dot)net