Обсуждение: Incrementing INET fields
Hi Guys Is there any particular reason why you can't do something like:select '10.1.1.1'::inet + 1; I would dearly like to be able to autoincrement an INET field. Even better I would like to be able to specify subnet or range limits on the autoincrement, but that would be just icing on the cake.. Is there some technical reason (other than finite developer time) that this isn't possible at present? Regards -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Mon, Nov 27, 2006 at 03:04:01PM +0200, Peter Nixonn wrote: > Is there some technical reason (other than finite developer time) that this > isn't possible at present? I don't think it makes much sense, without a fair amount of policy around it. For instance, you'd need to know what to increment to when you get to 10.1.1.254/32. Moreover, the mask range work you mentioned as "icing on the cake" is not icing at all: it's part of the cake, becase CIDR has been here for a long time. So you _have_ to be able to know what range you're in in order to do autoincrement. You could write a function that would do all this for you, though. A -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie
Peter Nixonn <listuser@peternixon.net> writes:
> Is there any particular reason why you can't do something like:
> select '10.1.1.1'::inet + 1;
There is such an operator in 8.2, though it's very simple-minded and
doesn't respond to any of Andrew's worries.
regards, tom lane
Andrew Sullivan wrote: > On Mon, Nov 27, 2006 at 03:04:01PM +0200, Peter Nixonn wrote: >> Is there some technical reason (other than finite developer time) that >> this isn't possible at present? > > I don't think it makes much sense, without a fair amount of policy > around it. For instance, you'd need to know what to increment to > when you get to 10.1.1.254/32. Moreover, the mask range work you > mentioned as "icing on the cake" is not icing at all: it's part of > the cake, becase CIDR has been here for a long time. So you _have_ > to be able to know what range you're in in order to do autoincrement. Yes. You are correct of course, however I am dealing with static IP assignment in FreeRADIUS for PPP clients and I just need to make sure that each user's IP is unique when added via a web interface. Being able to select the max ip and increment by one in a query would simplify my web code somewhat. On a related note we also wrote an ippool module for radius which needs to have a prepopulated sqltable of ip addresses which it then hands out. Being able to prepopulate the table with a 10.0.0.0/8 or 192.168.0.0/24 range with a simple loop would be very usefull. > You could write a function that would do all this for you, though. Yep. Sure. I have solutions for the situations I need, but every time I come across a new problem like this I need to reimpliment (sometimes poorly..) the a specific solution in my client code (perl and php for the most part). It would nice if Postgres took away this problem from me in the same way that it handles date and time arithmetic so wonderfully. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Tue, Nov 28, 2006 at 12:17:20AM +0200, Peter Nixonn wrote: > On a related note we also wrote an ippool module for radius which needs to > have a prepopulated sqltable of ip addresses which it then hands out. Being > able to prepopulate the table with a 10.0.0.0/8 or 192.168.0.0/24 range > with a simple loop would be very usefull. Seems to me you could do this with generate_series() and an int4 -> inet conversion function. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Tue, Nov 28, 2006 at 12:17:20AM +0200, Peter Nixonn wrote: > It would nice if Postgres took away this problem from me in the same way > that it handles date and time arithmetic so wonderfully. Well, I presume that the date and time arithmetic got there because someone needed it badly enough to write it. _Especially_ since this could be an add on component, it looks to me like an ideal candidate for pgfoundry. Now all it needs is an author. ;-) But you're right that, if you're scratching an itch, there's at least a chance that someone else has it. A -- Andrew Sullivan | ajs@crankycanuck.ca The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun