On Dec 6, 2011, at 12:06 PM, Robert Haas wrote:
> On Tue, Dec 6, 2011 at 1:00 PM, Euler Taveira de Oliveira
> <euler@timbira.com> wrote:
>> On 06-12-2011 13:11, Robert Haas wrote:
>>> On Tue, Dec 6, 2011 at 5:14 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>> I've been considering similar things, as you can find in the archives,
>>>> but what I was thinking of was converting the number to just a plain
>>>> bigint, then letting the user apply whatever arithmetic wanted at the
>>>> SQL level. I never got around to acutally coding it, though. It could
>>>> easily be extracted from your patch of course - and I think that's a
>>>> more flexible approach. Is there some advantage to your method that
>>>> I'm missing?
>>>
>>> I went so far as to put together an lsn data type. I didn't actually
>>> get all that far with it, which is why I haven't posted it sooner, but
>>> here's what I came up with. It's missing indexing support and stuff,
>>> but that could be added if people like the approach. It solves this
>>> problem by implementing -(lsn,lsn) => numeric (not int8, that can
>>> overflow since it is not unsigned), which allows an lsn => numeric
>>> conversion by just subtracting '0/0'::lsn.
>>>
>> Interesting approach. I don't want to go that far. If so, you want to change
>> all of those functions that deal with LSNs and add some implicit conversion
>> between text and lsn data types (for backward compatibility). As of int8, I'm
>> not aware of any modern plataform that int8 is not 64 bits. I'm not against
>> numeric use; I'm just saying that int8 is sufficient.
>
> The point isn't that int8 might not be 64 bits - of course it has to
> be 64 bits; that's why it's called int8 i.e. 8 bytes. The point is
> that a large enough LSN, represented as an int8, will come out as a
> negative values. int8 can only represent 2^63 *non-negative* values,
> because one bit is reserved for sign.
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?
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
