Re: big int

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: big int
Дата
Msg-id 007e01c0aa75$05eeb740$1001a8c0@archonet.com
обсуждение исходный текст
Ответ на big int  (newsreader@mediaone.net)
Список 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 по дате отправления:

Предыдущее
От: "Richard Huxton"
Дата:
Сообщение: Re: how do i create trigger with params?
Следующее
От: "Richard Huxton"
Дата:
Сообщение: Re: Money...