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 по дате отправления: