Skip site navigation (1) Skip section navigation (2)

Re: Summary: what to do about INET/CIDR

From: Larry Rosenman <ler(at)lerctr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alex Pilosov <alex(at)pilosoft(dot)com>, 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:24:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001027 17:04]:
> 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).
> Given the current proposal that inet_out should always display all 4
> octets, and the existing fact that inet_out suppresses display of
> a /32 netmask, the textual display of SELECT host(...) etc would
> remain the same as it is now.  But AFAICS you could do more with
> an inet-type result value, like say compare it to other inet or cidr
> values ...
> Comments?  Why was it done this way, anyway?
It doesn't bother me, as long as there is someway for me to get from a
CIDR type to 4 octets output with no mask indicated, and print the
broadcast and netmask and bits out separately from ONE column in the

I.E. for select
I get 

as output. 

Aside from that, I'm not picky. 

> 			regards, tom lane
Larry Rosenman            
Phone: +1 972-414-9812 (voice) Internet: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

In response to


pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-10-27 22:25:41
Subject: Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous:From: Bruce MomjianDate: 2000-10-27 22:15:40
Subject: Re: [HACKERS] Re:RPM dependencies (Was: 7.0 vs. 7.1 (was: latest version?))

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group