Re: [HACKERS] Re: inet/cidr/bind

> There is already concern that we are too close to the 6.4 final date to
> do anything with the INET type.  I am hearing that from another
> developer.

Yes.

> I am not sure what to advise, but adding a new type is not trivial.  It
> is going to require an initdb by everyone, because it is going to be in
> the regression test.

I propose that we rename CIDR to INET, base it on the existing inet_net_*
functions, and have done with it.  We can add IHOST next time.

> My personal opinion is that I am not ready to add a new type, and new
> duplicate functions for that type, this close to final.  I can add the
> type, and the pg_proc/indexing pointers to link in the existing
> inet functions, but full type inclusion is too much, I think.

I don't know how to help with this.

> For example, I have an inet_ops entry in pg_class.  I don't want to add
> an cidr_ops function that behaves exactly the same.  If we can't do this
> right, then we will not do it for 6.4.  My experience is that dumping
> partial solutions into 250k lines of code is a bad thing.

Yes.

> So, if people really want it, it has to be _good_.  If is not that
> important, it can wait.

I believe that I am to blame for the last minute nature of this, because I
was not properly focused on applications during the much earlier discussion.

Because we're at the end of our time, I propose that we rename the type to
INET, use the existing inet_net_ functions, and blow the bolts.