As we know, the inet and cidr types are still broken in several ways,
amongst others input and output functions, operators, ordering. I've
collected the bug reports from the last year or so from the archives.
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.
* 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.
* 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.
* 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.
* 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)'.
Does anyone see this differently? If not, can we agree on this
specification?
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
