From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Sevo Stille <sevo(at)ip23(dot)net> |
Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, pgsql-hackers(at)hub(dot)org |
Subject: | Re: INET/CIDR types |
Date: | 2000-07-25 02:13:57 |
Message-ID: | Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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)).
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2000-07-25 02:14:14 | Re: State of RPMs |
Previous Message | Hiroshi Inoue | 2000-07-24 23:55:32 | RE: Vacuum only with 20% old tuples |