Re: [HACKERS] New IP address datatype - Mailing list pgsql-hackers

Thus spake Mark Volpe
> I've been looking at those discussions -- my idea is to simplify
> the ip network types ( and operators ) a little:
> 
> Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and
> display 134.67.131.10.

darcy=> \d x
Table    = x
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| i                                | inet                             |   var |
| c                                | cidr                             |   var |
+----------------------------------+----------------------------------+-------+
darcy=> insert into x values ('134.67.131.0/24', '134.67.131.0/24');
INSERT 34272 1
darcy=> insert into x values ('134.67.131/24', '134.67.131/24');    
INSERT 34273 1
darcy=> insert into x values ('134.67.131', '134.67.131');      
ERROR:  could not parse "134.67.131"
darcy=> insert into x values ('134.67.131.0', '134.67.131');
INSERT 34274 1

Note how 134.67.131 is a valid cidr but not a valid inet.  Now look
how they display.

darcy=> select * from x;
i              |c            
---------------+-------------
134.67.131.0/24|134.67.131/24
134.67.131.0/24|134.67.131/24
134.67.131.0   |134.67.131/24
(3 rows)

As inet types, all octets are displayed.  In the last case, it assumes
a host and displays accordingly.  Note that while cidr will accept the
old classfull syntax, it displays using proper cidr format.

> Subnets are specified as '134.67.131.0/24', '134.67.131/24', or
> just '134.67.131', but they would display '134.67.131.0/24'.

As an inet type.  As a cidr type they should display as above.  You
seem to be confusing two concepts.

> There would be no provision for storing a host/netmask in the
> same structure; it seems confusing to me anyway since you could
> put the netmask in a seperate column.

You could and, if all you want to store is a netmask, you could store
the number of bits in an int.  If, however, you want to track a network
(cidr) or a host with all it's network information (inet) then they
should be in one type.  Hosts can be stored in inet simply by leaving
off the bits part.

So, if you combine the types, will the new type act like a cidr or an inet?
Personally, I wouldn't kick if a third type (host) was created just to
allow for a type that doesn't allow network information to be included.
Different input (just doesn't allow the slash) and everything else like
the inet type.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.