Re: Repair plan for inet and cidr types

Thus spake Peter Eisentraut
> There's apparently a lack of understanding of what exactly are these types
> are supposed to do. Therefore, instead of addressing each bug
> individually, let me first state what I reconstructed as the specification
> of these types, and then add what is currently wrong with it.

I have been browsing through the old messages on the topic. There was, in
fact some very good work defining the type before anyone actually started
to code. There was a surprising amount of controversy over the actual
definitions but I think in the end we hammered it out at least to the
point that everyone could work with it.

> * CIDR
>
> The cidr type stores the identity of an IP _network_. A network
> specification is of the form 'x.x.x.x/y'. The documentation states that if
> y is omitted then it is constructed from the old A, B, C class scheme. So
> be it. In a real world network, the bits (y+1)...32 have to be zero, but
> the cidr type does not currently enforce this. This has been the source of
> bugs in the past, and no doubt the source of some confusion as well. I
> propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think
> about it, this is the same as int4 rejecting 3.5 as input.

There is also the option of accepting it but masking out the host bits
before storing it. That gives us automatic conversion if we store an
inet into a cidr if our intent is to store the network part.

What sort of bugs do you think it caused btw?

> * INET
>
> The inet type stores the identity of an IP _host_. A host specification is
> of the form 'x.x.x.x'. Optionally, the inet type also stores the identity
> of the network the host is in. E.g., '127.0.0.5/16' means the host
> 127.0.0.5 in the network 127.0/16.

That sounds right. We also allowed for hosts to be stored implicitely by
simply making the netmask /32.

> * Type equivalency
>
> This has also been a source of problems. I propose that cidr and inet are
> not made equivalent types at any level. No automatic casting either. A
> network and a host are not the same thing. To construct a cidr value from
> an inet value, you'd have to use some sort of (to be created) network()
> function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no
> reasonable way to construct an inet value from a cidr value.

I'm not sure I understand why this is necessary. I can see not allowing
cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
of dropping information - the host part.

> * Operators
>
> Because the types are equivalent, the operators have also been bunched
> together in confusing ways. I propose that ordering operators (>, +, <)
> between inet and cidr be eliminated, they do not make sense. The only
> useful operation between cidr and inet is the << ("contains") operator.
> Ordering withing cidr and inet be defined in terms of their bit
> representation, as is the case now. The << family of operators should also
> be removed for the inet type -- a host cannot "contain" another host. What
> you probably wanted is `inet1 << network(inet2)'.

Then let's define that as the meaning of "inet1 << inet2" i.e. define
the << operator between inet types as meaning "tell me if inet1 is in
the same network as inet2." In fact, if we define << as only allowed
between inet and cidr (or cidr and cidr?) then the implied cast will
deal with it if that cast causes the host bits to drop as suggested
above.

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.