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

> > Thus spake Paul A Vixie
> > > Since other people want to use this type differently, I propose that we make
> > > it into two types: INET for host addresses and CIDR for network addresses.
> > > Both can include /## to set a netmask if folks really don't like making the
> > > address and netmask into two adjacent columns.  But CIDR has to disallow
> > > nonzero host-parts or it doesn't mean what I need it to mean.

Paul, can you give the unknowledgable among us an example of what you
want and don't want?  Thanks.

I was assuming the type would allow these as hosts:
192.4.13.42192.4.13.42    255.255.255.0192.4.13.42/32192.4.13.42/32 255.255.255.0

and these are networks:
192.63.91.234/28192.63.91.234/28 255.255.255.128

Any non-32 '/' is a network?  Can a network have a netmask?  Not sure.
Internally, a -1 in a field indicates the user did not supply a cidr
value(assume it is a host), or did not specify a netmask.  I thought
this is where D'Arcy was going with this.

I assume we are _not_ going to use the /24 notation to specify a
netmask, because the cidr '/' notation has never been used for that,
right?
> > 
> > I am cool with this.  In fact I think I mentioned earlier in the thread that
> > this requirement (it was a theoretical possibility to me at the time) was
> > the one reason why two different types might be required.  OK so that
> > means that, as I suggested, we need two underlying function sets, the
> > inet_net_* ones and the inet_cidr_* ones (might be some efficiency
> > possible if they are in the same source file and use some common
> > routines) and the original inet.c file gets changed to cidr.c and
> > turned into the cidr type.  I'll take the existing inet.c as it exists
> > on my system and submit it as the _new_ inet type.
> 
> Sorry, but I just have to ask.  I am not sure what the issues are, but
> it is possible to have them all be the same type.  Have a netmask field
> inside the type and a cidr field inside the type, and just use one of
> them at a time for any given entry?  Only one byte each, right?  I sure
> would like to avoid "type/function bloat".  Also, could a RULE be
> created to simulate the network restriction Paul requires?
> 
> Maybe it is clearer to have two types, with different purposes.  I am
> just asking, and if people are going to need functions to convert
> between the two types, it may be worth merging them.  I was thinking you
> could display them differently based on which field they used.
> 
> This is all just a guess.

If I am wrong about the above, I have one more question.  Would an
atttypmod setting for each column help?  What about a compile-time
define?

I know Paul is a big name, but are the duplicate types meaningful for
ordinary users, or would they prefer just one type.  If they would
prefer one type, we can do that, and make sure Paul gets what he wants
too.

Want something really fancy?
CREATE TABLE hostnet(    host     inet(host),    network    inet(net),    misc    inet);

This is possible.

If we can get some more rapid-fire e-mails going around, I think we can
resolve this in the next day or two.  We have testing and documenation
to do, and Marc at some point may pull the plug on us.

I am ready to install whatever you folks come up with.

If we can come up with one type, that is less bloat/work for me, but my
primary goal is that we come up with a solid type/types that we aren't
going to need to redesign in the future, causing problems for existing
users.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026