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

From: darcy(at)druid(dot)net
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Subject: Re: [HACKERS] Re: inet/cidr/bind
Date: 1998-10-20 13:51:21
Message-ID: m0zVcCx-0000f3C@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thus spake Bruce Momjian
> > However, let's get the two types in right now with two separate groups
> > of functions and fold them after the release. It won't change the
> > user interface. Unless we think we can do it quickly.
> >
> > In any case, maybe we can add the flag now since we figure we'll need
> > it later anyway.
>
> Once we put entries in the system tables, those really are not going to
> change dramatically until 6.5.

While I would like everything in there now, I can live with this as long
as the user interface doesn't change.

How about this? We now have an inet type pretty much completed. Let's
put that back in right now. copy all the files involved, substitute
inet to cidr in the function names and make it the new cidr type. Once
we agree on which one is the host+netmask type add the extra functions
for netmask, masklen, host, network_without_bits, network_with_bits and
broadcast making them stubs if necessary. I'll get my code into the
right file as soon as possible. Later we can fold things in better
but we can do it without changing the catalogues. If it makes it more
efficient we can change the catalogue where 6.5 comes out.

If we can do this right away I think we have a good chance of getting
it into 6.4 properly anyway.

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

Of course this is your decision. We have the inet type now and as long
as we know what that type is, we can always add the other for 6.5 if
we can't get it in now.

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

So far less than a half dozen people are really involved in this discussion.
How about a quick straw poll of who really wants this in?

> These are my opinions, and of course, can be over-ruled.

Not if you need to do the work on the catalogues they can't. :-)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sferacarta Software 1998-10-20 13:52:06 using indexes with the OR clause
Previous Message D'Arcy J.M. Cain 1998-10-20 13:27:51 Re: [HACKERS] Re: inet/cidr/bind