From: | Paul A Vixie <paul(at)vix(dot)com> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: inet/cidr/bind |
Date: | 1998-10-20 06:25:25 |
Message-ID: | 199810200625.XAA07583@bb.rc.vix.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1998-10-20 08:24:09 | RE: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Paul A Vixie | 1998-10-20 06:21:37 | Re: [HACKERS] Re: inet/cidr/bind |