| 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: | Whole Thread | Raw Message | 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 |