BM> Greg Stark wrote:
>>
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>
>> > am thinking we should support only inet + inet, like this:
>> >
>> > SELECT '1.2.3.4'::inet + '0.0.1.2'::inet;
>>
>> I don't think inet+inet makes any sense.
>>
>> I think inet+int4 should work by adding to the host address and overflowing if
>> it exceeds the network mask.
>>
>> Ie,
>>
>> 10.0.0.0/24 + 1 = 10.0.0.1/24
>> 10.0.0.255/24 + 1 => overflow
>>
>> Or
>>
>> 10.1/16 + 1 = 10.1.0.1/16
>> 10.1/16 + 16384 = 10.1.64.0/16
>> 10.1/16 + 65536 => overflow
BM> So, do not overflow? We can do that. Another idea Tom had was creating
BM> a function that increments/decrements the address or the network portion
BM> of the address, and if you increment past the non-network portion that
BM> overflows too.
Hmm, actually, you can do several functions to increase/decrease
network address with different overflow models (octet-overflow,
host part overflow, full address overflow, or without overflow
as special case), for flexibility. Another question, what model choose for '+/-' ...
BTW, why 'inet + int4' (not int8), what about v6 ?
Few words for 'inet + inet'. It's can be useful for IPv6 addresses
(because you don't have 128-bit numeric type, except, maybe, 'numeric'
one). But, there is another way to reach higher octets - use existing
inet_{send|receive} functions.
<disclaimer text='raw ideas and thoughts'>
Or invent something new like this:
-- <src> <index> <value>
FUNCTION extract_octet(inet, integer) RETURNS integer
FUNCTION extract_word (inet, integer) RETURNS int2
FUNCTION extract_dword(inet, integer) RETURNS int4
FUNCTION extract_qword(inet, integer) RETURNS int8
-- <src> <index> <value>
FUNCTION replace_octet(inet, integer, integer) RETURNS inet
FUNCTION replace_word (inet, integer, int2) RETURNS inet
FUNCTION replace_dword(inet, integer, int4) RETURNS inet
FUNCTION replace_qword(inet, integer, int8) RETURNS inet
(not established with signed 'int%')
</disclaimer>
Ilya A. Kovalenko
