Re: inet/cidr ipv6 operations

On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Chris Angelico <rosuav(at)gmail(dot)com> writes:
>> Or alternatively, does PostgreSQL have any integer type larger than
>> 64-bit bigint? I've become accustomed to using bignums in most of my
>> programming; arbitrary-precision integers allow all sorts of handy
>> flexibilities. Are there any plans to add bignums (something like
>> GMP's mpz) to the engine?
>
> It's hard to muster much excitement about that when we've already
> got "numeric".

True, but I wasn't able (with 9.1, so that might have changed since)
to add inet to numeric. Maybe that would be easier?

I don't think inet + inet is the right thing for this. It would make
just as much sense for inet '2000::/16' + inet '2001::/16' to equal
inet '2000::/15', so it's not going to "read" as clearly. Expanding
the "netblock + number" concept to numeric makes reasonable sense.

> As far as the OP's problem goes, I wonder if there wouldn't be some use
> in an inet+(big)int function that does shift-and-add, ie move the
> integer over by the number of bits that have to remain zero according to
> the netmask. I'm not seeing the use for adding enormous random integers
> to IP addresses --- but "three over from this /64 block" doesn't seem so
> improbable.

Interesting. Not sure what sort of syntax would work there, but it
does grok well. Instead of thinking about an IPv6 block as a 128-bit
integer plus a tag, you can treat it as an N-bit integer, where N is
the CIDR length. I like it! And assuming your blocks are /64 or
larger, that'd cover all logical uses (I can imagine, for instance,
adding 65536 to a /64, but not adding 2^63).

ChrisA