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.