Re: INET/CIDR types - Mailing list pgsql-hackers

> This whole discussion is quite silly guys.
> 
> It is quite reasonable to have ability to split CIDR net into two pieces:
> the network and the bitshift. Second one is already possible, the first
> one can be accomplished by having functions to convert a cidr/inet to int8
> (not int4 because of sign thing), and back.
> 
> Its also very easy to implement ;)
> 
> This will actually come very useful for many applications. Something I'm
> working on now (allocation of 'most appropriate' block) requires ability
> to split a netblock into two, which could be most easily accomplished
> using int8 math. (net::int8+2^(netmask(net)-1)).
All I'm looking for is to be able to print all 4 octets of an IP address
out so that joe user can take the 4 numbers and type it into the 
4 boxes on a Windows 98 box, and use them. 

Is that really that abhorrent?

They also need the 4 octet netmask which I can get now. 

All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
for the output.  It's not asking for classful, and for sure
we use CIDR all over the place, but for the final output that my
users see, why can't I have the database just print all 4 octets?

Why is this discussion so hard?

Larry
> 
> Now, patch anyone? :)
> -alex
> On Tue, 25 Jul 2000, Sevo Stille wrote:
> 
> > Larry Rosenman wrote:
> > > 
> > > The problem is NON-TECHNICAL people will be getting the output,
> > > and they expect 4 octet output.
> > 
> > Well, but what are they going to do if they see, say, that 196.100.0.0
> > is already allocated? Any CIDR net starting off on the .0 will have
> > exactly the same 4 octet notation. That is, the above entry would only
> > tell that there is some indeterminable number of addresses starting off
> > 196.100.0.0 allocated, which could be anything between a measly /31 and
> > a whopping big /16. To repeat: CIDR having no implicit netmask encoded
> > in the class, there is no way of figuring out your allocation if you
> > lose the explicit mask. Which presumably will cause considerable
> > problems in a network allocation and tracking application!
> >  
> > > I really think that we should have a way to coerce a CIDR to
> > > an INET, and then allow host().
> > 
> > There is no unique mapping of a CIDR network to a INET host address,
> > except for the special case of /32. 
> >  
> > > Remember that I am dealing with $10/hour clerks.
> > 
> > Then given them a interface which makes the concept of CIDR obvious to
> > them. Faking a classed notation is no way to go! IP v.4 being what it
> > is, and registries being on the move to enforce CIDR more and more, they
> > will inevitably encounter CIDR sooner or later, probably in a business
> > critical way.  
> >  
> > > I really don't get the hostility to changing the OUTPUT format...
> > 
> > Anything broken that is added will sooner or later be used by somebody.
> > Which means that it can't be fixed without breaking some applications.
> > That alone should be a good enough reason not to introduce any broken
> > notions intentionally.
> > 
> > Sevo
> > 
> > 
> 


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749