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);
CREATE
test=> insert into test values ('1.2.3.4','1.2.3.4');
INSERT 18474 1
test=> insert into test values ('1.2.3.4/32','1.2.3.4/32');
INSERT 18475 1
test=> insert into test values ('1.2.3.4/24','1.2.3.4/24');
INSERT 18476 1
test=> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026