From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cleaning up the INET/CIDR mess |
Date: | 2006-01-25 18:36:32 |
Message-ID: | 20060125183632.GD4474@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> I have a question in a different direction. What is the meaning of the network
> mask in the inet data type anyways? Hosts don't have network masks, only
> networks.
>
> If we could store inet in four bytes it would be vastly more efficient both in
> disk space usage and in cpu at runtime.
>
> I think it would also clear up the perpetual user confusion between the two
> datatypes. I posit that the main source of the confusion is that currently
> Postgres lets you use inet for everything, even if what you're really storing
> is a network address range which is what the cidr datatype is really for.
I wholeheartedly agree with this. It also makes the only cast option
from inet to cidr to be with a /32 and thus there's no zeroing of bits.
It would then be nice to have a function to which you pass in a cidr and
a netmask and say "give me the CIDR this CIDR is in with this mask".
With the inet-to-cidr implicit cast you could use this function to get
the CIDR you want without having to worry about the implicit cast
throwing data away. The cidr-to-inet is then throwing away the mask and
so I'm not sure we should have an implicit cast in that direction but
honestly I wouldn't complain if we did.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew - Supernews | 2006-01-25 18:38:54 | Re: Cleaning up the INET/CIDR mess |
Previous Message | Andrew - Supernews | 2006-01-25 18:30:47 | Re: Cleaning up the INET/CIDR mess |