Hi,
> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).
Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host" part of the add
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Douglas McNaught wrote:
> > Bruce Momjian writes:
> >
> > > I modified the TODO. I think we only need an INT4. I realize INT8
> > > would be for IPV6 but I can't imagine a network that has more than INT4
> > > hosts (not part of the network addr
Douglas McNaught wrote:
> Bruce Momjian writes:
>
> > I modified the TODO. I think we only need an INT4. I realize INT8
> > would be for IPV6 but I can't imagine a network that has more than INT4
> > hosts (not part of the network address).
>
> Actually "increment the host address" isn't a wel
Bruce Momjian writes:
> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).
Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host
Patrick Welche wrote:
> On Fri, May 20, 2005 at 11:12:54PM -0400, Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Allow INET + INT4/INT8 to increment the host part of the address, or
> > throw an error on overflow
> >
> > I have not heard any use-case for adding to the network value i
On Wed, Apr 20, 2005 at 12:30:08 +0800,
"Ilya A. Kovalenko" <[EMAIL PROTECTED]> wrote:
> GS> I see a use case for of generating addresses based on a sequence or some
> GS> primary key from the database.
>
> GS> Something like
>
> GS> CREATE SEQUENCE hosts_ip_seq MAXVALUE 65536;
> GS> ALTER TABL
GS> I see a use case for of generating addresses based on a sequence or some
GS> primary key from the database.
GS> Something like
GS> CREATE SEQUENCE hosts_ip_seq MAXVALUE 65536;
GS> ALTER TABLE hosts ALTER ip SET DEFAULT '10.0.0.0/16'::inet +
nextval(hosts_ip_seq')
hmm, not quite good idea -
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 over
On Tue, Apr 19, 2005 at 12:03:27 -0400,
Bruce Momjian wrote:
>
> Agreed. Let's implement '+/-' for 'inet + int4' and put it in the
> backend as standard (I can help do the system table stuff if you give me
> the C functions). However, how do we handle cases where int4 > 255. I
> am thinking
Bruce Momjian writes:
> > 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
>
> So, do not overflow?
You mean not doing modulus arithemtic? Ye
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
>
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
Ilya A. Kovalenko wrote:
> BM> Would you modify this so it can go in /contrib or pgfoundry? Is there
> BM> general interest for this?
>
> Actually, I suggested to do such or similar function as internal.
> PostgreSQL has inet/cidr - excellent data type and good facilities to
> examine and compa
On Mon, Apr 18, 2005 at 08:58:01PM -0400, Bruce Momjian wrote:
>
> Would you modify this so it can go in /contrib or pgfoundry? Is there
> general interest for this?
I was about to sit down and write the same function yesterday, when as if
by magic this appeared. In my case it is to loop over ip
BM> Would you modify this so it can go in /contrib or pgfoundry? Is there
BM> general interest for this?
Actually, I suggested to do such or similar function as internal.
PostgreSQL has inet/cidr - excellent data type and good facilities to
examine and compare inet values, but has no facilities
Would you modify this so it can go in /contrib or pgfoundry? Is there
general interest for this?
---
Ilya A. Kovalenko wrote:
>Greetings,
>
> I suggest function for "inet" increment w/ int8 (signed).
>
> FUNCTION in
oops
- FUNCTION inet_inc(int, int8) RETURNS inet
+ FUNCTION inet_inc(inet, int8) RETURNS inet
---(end of broadcast)---
TIP 8: explain analyze is your friend
Greetings,
I suggest function for "inet" increment w/ int8 (signed).
FUNCTION inet_inc(int, int8) RETURNS inet
Function, useful for making address pools (using also
existing "inet" compare functions to trap boundaries).
Notes:
This version lets address wrap around 0-*ff boundary.
Uses
18 matches
Mail list logo
