Re: [HACKERS] New INET and CIDR types - Mailing list pgsql-hackers

From darcy@druid.net (D'Arcy J.M. Cain)
Subject Re: [HACKERS] New INET and CIDR types
Date
Msg-id m0zW1CE-0000emC@druid.net
Whole thread Raw
In response to Re: [HACKERS] New INET and CIDR types  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] New INET and CIDR types
List pgsql-hackers
Thus spake Bruce Momjian
> > 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.

It does work.  More importantly we have the catalogues and API nailed
down.  There are some effeciencies and fine tuning that could be done
but I think what we have is good enough that documentation is now
more of a priority than code.

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

That's done.  The only thing is that now you have to manually put
the /32 on input.  I'll fix that very soon.

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

They could.  As I have said I wouldn't.  If I had to store a netmask
alone I would store it as a masklen in an integer.  To each his own
though.  What we have gives maximum flexibility I think.

> Functionality-wise, I like CHOST.

No one has objected so I will go forward on that basis.

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

Will you do it or shall I?

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


pgsql-hackers by date:

Previous
From: "Matthew N. Dodd"
Date:
Subject: Re: [HACKERS] CIDR/INET type and IANA/ICANN
Next
From: Paul A Vixie
Date:
Subject: Re: [HACKERS] CIDR/INET type and IANA/ICANN