From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | David Salisbury <salisbury(at)globe(dot)gov> |
Cc: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: timestamps, formatting, and internals |
Date: | 2012-05-30 02:08:07 |
Message-ID: | 4FC58107.5040805@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05/29/2012 04:28 PM, David Salisbury wrote:
>
>
> On 5/27/12 12:25 AM, Jasen Betts wrote:
>> The query: "show integer_datetimes;" should return 'on' which means
>> timestamps are microsecond precision if it returns 'off' your database
>> was built with floating point timstamps and equality tests will be
>> unreliable,
>
> I find that rather interesting. I was told that I was losing microseconds
> when I extracted an epoch from the difference between two timestamps and
> casted
> that value to an integer. So if I have integer timestamps ( your case
> above )
> I get microseconds, but integer epochs is without microseconds?
test=> SELECT extract(epoch from(now() - (now() - interval '1.345577 sec')));
date_part
-----------
1.345577
test=> SELECT extract(epoch from(now() - (now() - interval '1.345577 sec')))::int;
date_part
-----------
1
An integer is an integer so you will lose all the fractional parts:)
>
> Thanks,
>
> -ds
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Alan Gutierrez | 2012-05-30 02:20:55 | Re: Escaping `psql --variable` |
Previous Message | Adrian Klaver | 2012-05-30 02:01:24 | Re: Export and import from one postgres server to another |