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