Re: big int - Mailing list pgsql-general

From Richard Huxton
Subject Re: big int
Date
Msg-id 007e01c0aa75$05eeb740$1001a8c0@archonet.com
Whole thread Raw
In response to big int  (newsreader@mediaone.net)
List pgsql-general
From: <newsreader@mediaone.net>

> This isn't exactly related to pg but
> I thought some wise person might be able
> to explain.

Sorry - you got me instead ;-)

> i've been storing the number of seconds
> since  Dec 31 19:00:00 1969 whenever
> I have to store a time format. For this
> integer type is good.

I'd suggest "timestamp" for PG - handles big dates just fine.

> As we all know come year 2032 or so this
> number will exceed the range of integer.

Ssh - the 2038 crisis is bankrolling my retirement fund.

> If I want to prevent problems in the future
> should I use int8.  Is there significant
> overhead?  It seems that on an DEC/alpha
> 64 bit platform perl does not seems
> to be aware that it's not on a 32 bit platform.
> --------------
> % perl -MTime::Local -e 'print timelocal(9,9,9,9,9,200)' ;
> Can't handle date (9, 9, 9, 9, 9, 200) at -e line 1
> --------------

Odd - I get -1 returned (as per the docs) on Intel.

This particular feature is probably an artifact of implementation. I'd guess
the internal code gets integers translated as int4 because that's what it is
for most people.

Actually I think I'm talking rubbish - looking at the code for
Time::Local.pm you might be getting this error _because_ you are on a 64-bit
platform. Take a look at "sub cheat" (I _think_ line 114 might be the
problem).

For big date handling, I've always quite liked string representations.
Unfortunately, no good for calculations. If you can't find a Time::Big
module on CPAN I'd recommend checking out the perl.moderated newsgroup -
there are big guns there who know what they're talking about.

- Richard Huxton


pgsql-general by date:

Previous
From: "Richard Huxton"
Date:
Subject: Re: how do i create trigger with params?
Next
From: "Richard Huxton"
Date:
Subject: Re: Money...