Re: [HACKERS] New INET and CIDR types

Thus spake Bruce Momjian
> > 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.

For sure not the documentation. As for the regression testing, it should
be final by Friday. Unfortunately I'm having problems. The last sup
seems to have broken the inet type. I'll try to get you in #PostgreSQL
and talk about this.

> > 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 certain cases. I now have the functions from Paul so I should be able
to get that correct tonight if I can get the type working again.

> In fact, it may be supressing the /32 when it should not, like in the
> CIDR type:

Again, will be fixed when I plug in Paul's functions.

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

Internally it does. Paul said it doesn't matter and I assume it is
his function leaving it off though I haven't checked.

--
D'Arcy J.M. Cain <darcy(at){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.