On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Chris Angelico <rosuav@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
