Re: [HACKERS] New IP address datatype

Поиск
Список
Период
Сортировка
От Mark Volpe
Тема Re: [HACKERS] New IP address datatype
Дата
Msg-id 375414C0.640C4D45@eos.ncsu.edu
обсуждение исходный текст
Ответ на Re: [HACKERS] New IP address datatype  ("D'Arcy" "J.M." Cain <darcy@druid.net>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] LIMITS
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] LIMITS