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
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. |
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 |