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

From Mark Volpe
Subject Re: [HACKERS] New IP address datatype
Date
Msg-id 375414C0.640C4D45@eos.ncsu.edu
Whole thread Raw
In response to Re: [HACKERS] New IP address datatype  ("D'Arcy" "J.M." Cain <darcy@druid.net>)
List pgsql-hackers
"D'Arcy J.M. Cain" wrote:
> 
> 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.
> 

Actually I was talking about the behavior of my "unified" type :)

If I have:

CREATE TABLE x ( i ip4 );
INSERT INTO x VALUES('10.20.30.40');
INSERT INTO x VALUES('10.20.30');
INSERT INTO x VALUES('10.20');
INSERT INTO x VALUES('10.20.30/20');

I would have:

SELECT * FROM x;
i            
-------------
10.20.30.40  
10.20.30.0/24
10.20.0.0/16 
10.20.16.0/20

In most applications ( e.g., IP and network registration )
you would require that there be no overlapping address space,
so the above table would be illegal in a unique index. I thought
about creating two different operator sets, but that means if
you commit to one in a btree, using the other one always requires
a Seq Scan ( am I right here? ). So I used one and as a result,
the '=' operator checks if its two operands overlap ( I also
have operators for reading and coercing the masks ). Our group
uses this sort of thing and it works pretty well.
Thanks for your comments.

Mark


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] LIMITS
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] LIMITS