Re: inet increment w/ int8

From: Ilya A. Kovalenko
Subject: Re: inet increment w/ int8
Date: ,
Msg-id: 142147968847.20050420115325@oganer.net
(view: Whole thread, Raw)
In response to: Re: inet increment w/ int8  (Bruce Momjian)
List: pgsql-hackers

Tree view

inet increment w/ int8  ("Ilya A. Kovalenko", )
 Re: inet increment w/ int8  ("Ilya A. Kovalenko", )
 Re: inet increment w/ int8  (Bruce Momjian, )
  Re: inet increment w/ int8  ("Ilya A. Kovalenko", )
   Re: inet increment w/ int8  (Bruce Momjian, )
    Re: inet increment w/ int8  (Greg Stark, )
     Re: inet increment w/ int8  (Bruce Momjian, )
      Re: inet increment w/ int8  (Greg Stark, )
       Re: inet increment w/ int8  ("Ilya A. Kovalenko", )
        Re: inet increment w/ int8  (Bruno Wolff III, )
      Re: inet increment w/ int8  ("Ilya A. Kovalenko", )
    Re: inet increment w/ int8  (Bruno Wolff III, )
  Re: inet increment w/ int8  (Patrick Welche, )
 Re: inet increment w/ int8  (Bruce Momjian, )
  Re: inet increment w/ int8  (Douglas McNaught, )
   Re: inet increment w/ int8  (Bruce Momjian, )
    Re: inet increment w/ int8  (Stephen Frost, )
    Re: inet increment w/ int8  ("Sander Steffann", )

BM> Greg Stark wrote:
>> 
>> Bruce Momjian <> 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




pgsql-hackers by date:

From: Mario Weilguni
Date:
Subject: Re: ORDER BY different locales for 8.0
From: Klaus Naumann
Date:
Subject: Re: Problem with PITR recovery