Skip site navigation (1) Skip section navigation (2)

Re: xlog location arithmetic

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2011-12-13 20:37:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> I've often wondered about adding uint2/4/8... I suspect it's actually pretty uncommon for people to put negative numbers into 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 implicit casting between int and uint... that just means that we'd have to be smart about casting from unknown, but hopefully that'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
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-12-13 20:41:12
Subject: Re: JSON for PG 9.2
Previous:From: Merlin MoncureDate: 2011-12-13 20:36:04
Subject: Re: JSON for PG 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group