On Tue, Sep 08, 2009 at 05:11:02PM +0100, Sam Mason wrote:
> On Tue, Sep 08, 2009 at 05:58:01PM +0200, Kristian Larsson wrote:
> > On Tue, Sep 08, 2009 at 11:37:02AM -0400, Tom Lane wrote:
> > > I think the whole thing is a bit of a crock; adding integers to inet
> > > addresses doesn't make a lot of sense logically. Perhaps what is
> > > really wanted is functions on CIDR net identifiers, for instance
> [...]
> > For me, as a network engineer, adding an integer to a inet feels
> > quite natural. Inet is just another representation of a integer
> > anyway... so I'd really not have a problem with having either a
> > int16 or being able to add numerics to inets :)
>
> Indeed, it seems similar to the (somewhat arbitrary) decision that
> adding an int to a date results that many days being added to it.
> Timestamp INTERVALs may be more flexible, but it's a useful shortcut
> that I use quite often.
>
> Something to convert to/from a NUMERIC value and INET would seem useful
> as well.
I'd like to reach some form of consensus on what to do about
this.
Do we
a) ignore it and let users use the workarounds?
b) add a next_address() as per Toms suggestion ?
c) add a conversation between NUMERIC and INET so one can add a
NUMERIC to an INET just as is possible today with INTEGERs?
While Tom's suggestion about next_address might be convenient in
certain scenarios I think it would be nice to be able to add a
numeric to an inet. In other database systems you typically don't
have a inet type at all so people who handle IP addresses in
databases are used to working with integers and bit shifting et
al to do all the IP calculations that one might need. Based on
thie, I vote for option C.
What say you? Yay or nay? :)
Kind regards,
Kristian.
--
Kristian Larsson KLL-RIPE
+46 704 264511 kll@spritelink.net