Re: [HACKERS] New INET and CIDR types

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

OK.  Yes, you can continue cleaning things up.  I just want some
regression tests and documentation, and you can then continue, but I
hope they changes will not affect the contents of the documentation or
regression tests.  If you can concentrate on those changes first, then
the docs/regression, that would be good.


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

Actually, the /32 is not required.  It properly displays it if it was
supplied, and supresses it if it is not.

In fact, it may be supressing the /32 when it should not, like in the
CIDR type:
test=> create table test (x inet, y cidr);CREATEtest=> insert into test values ('1.2.3.4','1.2.3.4');INSERT 18474
1test=>insert into test values ('1.2.3.4/32','1.2.3.4/32');INSERT 18475 1test=> insert into test values
('1.2.3.4/24','1.2.3.4/24');INSERT18476 1test=> select * from test;x       |y       --------+--------1.2.3.4 |1.2.3.4
1.2.3.4|1.2.3.4 1.2.3/24|1.2.3/24(3 rows)
 

I would think the CIDR type should preserve the /32.

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

I can see cases where storing the netmask separately would be nice, and
it should display in a nice INET format.

> 
> > Functionality-wise, I like CHOST.
> 
> No one has objected so I will go forward on that basis.

Good.

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

Already done.

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