Re: c function returning high resolution timestamp

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

In response to

Responses

Browse pgsql-general by date

  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