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

Re: [HACKERS] Re: CIDR/IP types. Was: [GENERAL] big numbers

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: scrappy(at)hub(dot)org (Marc G(dot) Fournier)
Cc: tih(at)nhh(dot)no, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: CIDR/IP types. Was: [GENERAL] big numbers
Date: 1998-10-05 00:57:19
Message-ID: 199810050057.UAA29279@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 	*Please* make the appropriate changes and submit a patch...it
> should be listed as CIDR, not as IPADDR.  MACADDR, IMHO, is okay, as its
> the only way I've ever heard of it being referred...but I do not consider
> IPADDR to be correct terminology...

That is OK, but just let me that CIDR is for networks addresses, and
this type supports both host and network addresses.

Attached is a message from Paul Vixie mentioning this issue.  It argues
for the use of INET, rather than CIDR or IPADDR.

---------------------------------------------------------------------------


Replies to three messages here.

> From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> Date: Tue, 21 Jul 1998 01:13:34 -0400 (EDT)
>
> The only problem is that if we assume /32, how do we auto-netmask class
> A/B/C addresses?  I guess we don't.  If they want a netmask, they are
> going to have to specify it in cidr format.

Right.  But read on -- what you're calling a netmask is really a 
prefix length, and I think there's some confusion as to what it is.

> I will be honest.  I always found the network/host IP address
> distinction to be very unclearly outlined in old/non-cidr address
> displays, and this causes major confusion for me when trying to figure
> out how things are configured.

Me too.

> I like INET too.  It is up to you.

How do folks feel about polymorphism between IPv4 and IPv6?  Should we (a)
make it work (either by making internal_length=10 or going variable length)
or (b) just make this thing IPv4 only and take care of IPv6 separately/later?

I've started to wonder if we ought to call the type INET and limit it to V4.
(In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and
the address family is AF_INET6 -- I don't know whether to plan on reflecting
this in the postgres types, i.e., use a separate one for IPv6, or not.)

> From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT)
>
> > ...  but why would you want to know the mantissa without the scale?
> 
> I guess I thought someone might want to have ipaddr() and netmask()
> functions so they can do:
> 
> 	x = 192.7.34.21/24
> 	ipaddr(x)  -> 192.7.34.21
> 	netmask(x) -> 255.255.255.0

This is the downreference from above.  It does not work that way.  /24 is
not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length".
That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent
to "192.7.34/24".

Btw, it appears from my research that the BIND functions *do* impute a "class"
if (a) no "/width" is specified and (b) the classful interpretation would be
longer than the classless interpretation.  No big deal but it qualifies 
something I said earlier so I thought I'd mention it.

> 	x = 192.7.0.0/16
> 	ipaddr(x)  -> 192.7.0.0
> 	netmask(x) -> 255.255.0.0
> 
> These function are defined on the cidr type, and can be called if
> someone wants the old output format.

Can we wait and see if someone misses / asks for these before we make them?

> ..., the 127.1 ambiguity was very strange.  netstat -rn is very hard to
> understand using the old format.

I was amazed at the number of people who had hardwired "127.1" though :-(.

> From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> Date: Tue, 21 Jul 1998 01:33:41 -0400 (EDT)
>
> Doing complex stuff like indexing with contrib stuff is tricky, and one
> reason we want to move stuff out of there as it becomes popular.  It is
> just too hard for someone not experienced with the code to implement. 
> Add to this the fact that the oid at the time of contrib installation
> will change every time you install it, so it is even harder/impossible
> to automate.

Perhaps we ought to make new type insertion easier since it's so cool?




-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


In response to

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-10-05 01:19:32
Subject: Re: [COMMITTERS] 'pgsql/doc/src/sgml protocol.sgml'
Previous:From: Thomas G. LockhartDate: 1998-10-05 00:57:02
Subject: Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken

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