Re: [HACKERS] [Fwd: [ANNOUNCE] ipaddr data type - EXTENDED VERSION HERE]

>     alex@Relcom.EU.net, hackers@postgreSQL.org
> Subject: Re: [HACKERS] [Fwd: [ANNOUNCE] ipaddr data type - EXTENDED VERSION HERE]
>
> Sorry I haven't commented on this earlier, but I have been very busy,
> among other things becoming a father for the first time!  :-)
>
> dg@illustra.com (David Gould) writes:
>
> > Is this user-application compatible with our existing ip/contrib
> > handling?
>
> Mostly, yes.  Aleksei Roudnev did a great job adding indexing to my IP
Yes, except INPUT/OUTPUT functions. The 'ipclass' contributed into PSQL
before have the strict concept of 'IPADDR is SUBNET always, this mean it
have not HOST bits at all_. My concept was:

- ipaddr consist of IPADDRESS and MASK; this mean you can store both
NETWORKS and INTERFACE ADDRESSES, and you can easyly found all router
interfaces connected to the same network, for example;
- input and output functions use /PREFIX form of address with 2
exceptions:

(1) HOST (/32) address and last byte is not '0';
(2) A, B or C network address, and last 3, 2 or 1 bytes is ZERO.

This was done becuase it's near intuitive writing we use widely - if we
treat '193.124.23.0' as host address, or you treat '193.124.23.4' as
network address, it's out of common usage; all other cases you use
'/prefix' form.

In addition, there is 6'th byte of the 'ipaddr' structure not used yet,
(exactly my idea was to use it for 'undefined' values but I did not
checked my realisation of this).




> address data type, for which I'm very grateful, and he also added some
> functions that can come in handy.  Good work!  I'll certainly be using
> his index building technique extensively!  However, it should be noted
> that he's also built some assumptions into the current code that may
> not be expected by all users.  In particular, I dislike the hardcoding
> of the notion of class A, B and C network, since that's outdated and
> deprecated these days.
>
> On the other hand, Aleksei has done some good thinking on how subnet
> mask specifications can be useful in the data base, doing things like
> storing router interface addresses and their netmasks in the same
> record, as in 193.124.23.6/24.
>
> Alex: maybe we can sort this out and put together a "final" version
> that combines the best ideas?  There's a whole unused byte in the data
> structure right now, that could be put to use...
>
> -tih
> --
> Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"
>

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)