Re: Problem migrating dump to latest CVS snapshot.

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gunnar R|nning <gunnar(at)candleweb(dot)no>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem migrating dump to latest CVS snapshot.
Date: 2001-03-23 03:05:30
Message-ID: 3ABABD7A.B01950C9@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

(moved to -hackers, since I don't have posting privileges on -general)

> I've suggested before that timestamp output should round the timestamp
> value to two fractional digits *before* breaking it down into year/
> month/etc. Seems like this is a perfect example of the necessity
> for that. Thomas, what say you?

Well, that is a good idea to solve the "hidden digits problem",
introducing instead a new "lost digits feature". But I've been hoping to
hear a suggestion on how to allow a variable number of digits, without
cluttering things up with output values ending up with a bunch of 9's at
the end.

When I first implemented the non-Unix-time date/time types, I was
worried that the floating point math libraries on *some* of the two
dozen platforms we support would tend to print out .9999... values
(having seen this behavior *way* too often on older Unix boxes). But
I've never actually asked folks to run tests, since I was just happy
that the floating point implementation worked well enough to go into
production.

Thoughts?

- Thomas

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message datactrl 2001-03-23 03:16:37 psql slow connection
Previous Message Tom Lane 2001-03-23 02:52:43 Re: Problem migrating dump to latest CVS snapshot.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-23 03:27:20 Re: Problem migrating dump to latest CVS snapshot.
Previous Message Thomas Lockhart 2001-03-23 02:59:24 Re: Regression testing on Irix