Re: xlog location arithmetic - Mailing list pgsql-hackers

From Robert Haas
Subject Re: xlog location arithmetic
Date
Msg-id CA+TgmoZfK3LgCSz7D0O4r4HM4zNGrrNVftueAkTgxq-g3Jeddg@mail.gmail.com
Whole thread Raw
In response to Re: xlog location arithmetic  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby <jim@nasby.net> wrote:
> I've often wondered about adding uint2/4/8... I suspect it's actually pretty uncommon for people to put negative
numbersinto int fields, since one of their biggest uses seems to be surrogate keys. 
>
> I realize that this opens a can of worms with casting, but perhaps that can be kept under control by not doing any
implicitcasting between int and uint... that just means that we'd have to be smart about casting from unknown, but
hopefullythat's doable since we already have a similar concern with casting unknown to int2/4/8 vs numeric? 

I've wondered about it too, but it seems like too large a can of worms
to open just to address this case.  Returning the value as numeric is
hardly a disaster; the user can always downcast to int8 if they really
want, and as long as it's < 2^63 (which in practice it virtually
always will be) it will work.  It's not clear what the point of this
is since for typical values numeric is going to take up less storage
anyway (e.g. 1000001 is 7 bytes on disk as a numeric), not to mention
that it only requires 4-byte alignment rather than 8-byte alignment,
and probably no one does enough arithmetic with LSN values for any
speed penalty to matter even slightly, but it should work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: JSON for PG 9.2
Next
From: Peter Eisentraut
Date:
Subject: Re: JSON for PG 9.2