On Sun, Jan 30, 2005 at 09:49:43PM -0600, Larry Rosenman wrote:
> On Sun, 30 Jan 2005, Tom Lane wrote:
>
> >Steve Atkins <[EMAIL PROTECTED]> writes:
> >>For a replacement type, how important is it that it be completely
> >>compatible with the existing inet/cidr types? Is anyone actually using
> >>inet types with a non-cidr mask?
> >
> >If you check the archives you'll discover that our current inet/cidr
> >types were largely designed and implemented by Paul Vixie (yes, that
> >Vixie). I'm disinclined to second-guess Paul about the external
> >definition of these types; I just want to rationalize the internal
> >representation a bit. In particular we've got some issues about
> >conversions between the two types ...
>
> Please do **NOT** break the external representations. We had enough fights
> about that 2-3 releases ago, and I personally don't want to revisit them.
> Yes, we do flakey things with inet on the masking stuff.
Well, if you want the ability to store both a host address and a
netmask in the same datatype the inet masking stuff makes sense.
That's not really a useful datatype for any actual use, but it's
fairly well-defined. The problem is that when someone looks at the
docs they'll see inet as the obvious datatype to use to store IP
addresses, and it isn't very good for that.
But that's not all that's flakey, unfortunately.
The CIDR input format is documented to be classful, which in itself is
horribly obsolete and completely useless in this decades internet (and
was when the current code was written in '98).
But the implementation isn't either classful or classless, and the
behaviour disagrees with documented behaviour, and the behaviour you'd
reasonably expect, in many cases.
-- Class A - documented to be 10.0.0.0/8
steve=# select '10.0.0.0'::cidr;
cidr
-------------
10.0.0.0/32
-- Class B - documented to be 128.0.0.0/16
steve=# select '128.0.0.0'::cidr;
cidr
--------------
128.0.0.0/32
-- Class C - documented to be 223.10.0.0/24
steve=# select '223.10.0.0'::cidr;
cidr
---------------
223.10.0.0/32
-- Class D
steve=# select '224.10.0.0'::cidr;
ERROR: invalid cidr value: "224.10.0.0"
DETAIL: Value has bits set to right of mask.
steve=# select '224.0.0.0'::cidr;
cidr
-------------
224.0.0.0/4
-- Class E
steve=# select '240.10.0.0'::cidr;
cidr
---------------
240.10.0.0/32
I use postgresql for network-related applications and for IP address
related data mining, so I'm dealing with IP addresses in postgresql
on a daily basis.
The cidr type, including it's external interface, is simply broken.
There is no way to fix it that doesn't change that external interface.
I know of at least two independant implementations of function IP
address types that have been put together for specific projects to
implement a working IP datatype. The ability to use gist indexes on
them to accelerate range-based lookups is a bonus.
If it's not possible (for backwards compatibility reasons) to fix
inet+cidr, would migrating them out to contrib be a possibility?
Data types in the core tend to be widely used, even if they're
broken and there are better datatypes implemented as external
modules.
Cheers,
Steve
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
