Re: [HACKERS] New INET and CIDR types

Thus spake Bruce Momjian
> I have recieved the files from D'Arcy for new INET and CIDR types.  INET
> is use for hosts, while CIDR for networks.  No duplicate code.  CIDR
> behaves the same as INET, except for a different input function.  The
> system catalogs take care of the mapping of CIDR to INET functions.
> 
> It will require an initdb for beta users moving to 6.4 final.  Is this
> OK?  If so, I will apply it tomorrow.  If not, the type will have to be
> disabled for 6.4.

Just to clarify, what we have done (are doing) is to rename the existing
inet type as cidr.  This means that the CIDR type is now for CIDRized
networks as Paul originally proposed.  There are functions to extract the
various components such as netmask, broadcast address and mask length.

The INET type is now for either hosts or hosts plus networks.  The
code is not quite perfect yet but it compiles and works if you enter
a host as x.x.x.x/32.  We'll try to improve it before 6.4 but at
least the catalogues are set up so we can fine tune the type without
doing an initdb or changing the user API.

Between 6.4 and 6.5 we'll work on improving the type.  While the
catalogues won't change, we can modify the underlying code.  The
decision, which we should really make now for the documentation,
is what type to make it.  Remember that we identified 3 types, INET,
IHOST and CHOST.  With the name change we can call the first one CIDR
now.  The question is, what type should the new inet type represent,
IHOST or CHOST?

IHOST is meant to hold a host only.  To specify a host and the
network information using IHOST would require also using CIDR.

CHOST is meant to hold a host and network information in the same
type.  It can hold an IHOST by itself if desired.  There are
functions to extract the various components such as host, netmask,
broadcast address and mask length.

As you have probably guessed, I vote for CHOST.

Paul, can you send me the new functions that you wrote?  These will
be needed for the new type either way.  Hopefully I can fold it in
before 6.4.

> If I don't hear any objections, I will do it some time around noon
> tomorrow, EST.

Of course, all of the above is assuming that everyone accepts this
change.

Bruce, I was thinking that since cidr.c consists of a single function
and it uses most of the code in inet.c anyway, why don't we just fold it
into inet.c instead of having a whole file for it?

This is almost as much work as my day job.  And after 6.4 is released
I get to go through the same thing for the next release of PyGreSQL.

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