Re: [HACKERS] New IP address datatype

From: Mark Volpe <mvolpe(at)eos(dot)ncsu(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] New IP address datatype
Date: 1999-06-01 17:13:36
Message-ID: 375414C0.640C4D45@eos.ncsu.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-06-01 17:27:25 Re: [HACKERS] LIMITS
Previous Message Bruce Momjian 1999-06-01 16:33:23 Re: [HACKERS] LIMITS