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.

These functions also work for INET too.

> 
> 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.

We have to get it working OK in the next day, then any changes go into
post 6.4 minor releases.  We have regression tests and can't be changing
things.

I would like the INET type to not display/require the /32 anymore.

> 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.

People could just put a netmask in the field, so INET seems more
generic.

Functionality-wise, I like CHOST.

> 
> 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.

No objections yet.

> 
> 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?

OK.
> 
> 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.

Join the club.  It is usually _harder_ than my day job, but it is not as
often as my day job.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026