Dear Tom, dear Kevin
In fact "show integer_datetimes;" returns "off". As such there is a perfect
reason for this rounding. I assumed wrongly this being a bug. Sorry :-)
I understand as well your arguments on why not to use such a value for
infinity. The reason why I used it was because I ported this data from a
mainframe DB2 database where this value by tradition represented a high
value and NULL values not being used for compatibility in regards to the
mapped data type in PL1 and pure text-file processing of the same data. In
these programs the length of the year part of a timestamp is limited to 4
digits. This is where I noted the rounding which had occurred as a result of
my data imports into Postgresql.
Thanks again for your information and sorry for the disturbance :-)
Regards,
Matthias
On Fri, Jul 31, 2009 at 11:00 PM, Kevin Grittner <
Kevin.Grittner@wicourts.gov> wrote:
> "Matthias" <matthias.cesna@gmail.com> wrote:
>
> > I noticed an unusual (and from my point of view inconsistent)
> > rounding of a timestamp:
>
> What do you get when you run?:
>
> show integer_datetimes;
>
> If it is off, which is probably the default for your distribution
> under 8.3.X, timestamps are floating point (approximate) values which
> get less precise as you move away from the base timestamp of
> '2000-01-01 00:00'.
>
> The default under 8.4 is to use integer timestamps, which have a
> microsecond precision across the range they support. (That range is
> not as broad as the floating point format, but plenty large for most
> practical uses.)
>
> You can configure PostgreSQL to use integer timestamps in 8.3 if you
> build from source, but you will need to convert your database.
>
> -Kevin
>
