| From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alex Pilosov <alex(at)pilosoft(dot)com>, Larry Rosenman <ler(at)lerctr(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Summary: what to do about INET/CIDR |
| Date: | 2000-10-27 22:42:03 |
| Message-ID: | Pine.BSO.4.10.10010271833010.22890-100000@spider.pilosoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 27 Oct 2000, Tom Lane wrote:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet with masklen = 32
> (except for network(), which would keep the original masklen while
> coercing bits to its right to 0).
I absolutely agree, except for network(), which should return cidr.
(after all, this is the network).
As I mentioned in another email, should inet datatype really care whether
host part is all-ones or all-zeros and reject that? It would make sense to
me (10.0.0.0/8::inet is not a valid address, but 10.0.0.0/8::cidr is), but
it would break some people's scripts...
I'm talking here from a perspective of a network provider with P
knowledge...I'm sure Marc can chime in here...
-alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2000-10-27 22:43:56 | Re: Summary: what to do about INET/CIDR |
| Previous Message | Tom Lane | 2000-10-27 22:41:50 | Re: Summary: what to do about INET/CIDR |