From: | Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> |
---|---|
To: | Ron Peterson <ron(dot)peterson(at)yellowbank(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: c function returning high resolution timestamp |
Date: | 2006-10-20 13:32:05 |
Message-ID: | 87lknb2jvu.fsf@gate450.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ron Peterson writes:
> On Wed, Oct 18, 2006 at 04:43:40PM -0400, Ron Peterson wrote:
> I'm pretty close, but I'm still not understanding something about
> PostgreSQL's internal timestamp representation. If I do 'select
> now();', I get a return value with microsecond resolution, which would
> seem to indicate that internally, PostgreSQL is using an INT64 value
> rather than a float to hold the timestamp.
Floating point timestamps /do/ have microsecond resolution over a
limited range:
,----[ <http://www.postgresql.org/docs/8.1/static/datatype-datetime.html> ]
| Microsecond precision is achieved for dates within a few years of
| 2000-01-01, but the precision degrades for dates further away. When
| timestamp values are stored as eight-byte integers (a compile-time
| option), microsecond precision is available over the full range of
| values.
`----
> My function below, however, always takes the float path through the
> ifdef. If I force the int64 path, I just get a garbage timestamp
> which still only has a seconds resolution.
The proper way to enable the int64 path is enabling integer timestamps
during build-time:
,----[ ./configure --help|grep time ]
| --enable-integer-datetimes enable 64-bit integer date/time support
`----
regards,
andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Harald Armin Massa | 2006-10-20 13:37:29 | Re: why not kill -9 postmaster |
Previous Message | Alvaro Herrera | 2006-10-20 13:29:54 | Re: why not kill -9 postmaster |