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
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 |