Re: fixes for date_part micro/millisecond precision
От | Tom Lane |
---|---|
Тема | Re: fixes for date_part micro/millisecond precision |
Дата | |
Msg-id | 29599.1006633947@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fixes for date_part micro/millisecond precision (Brent Verner <brent@rcfile.org>) |
Ответы |
Re: fixes for date_part micro/millisecond precision
|
Список | pgsql-patches |
Brent Verner <brent@rcfile.org> writes: > ... if I insert a timestamp of > '2001-1-1 11:11:11.12341234-05' I /really/ want to get back '12341234' > when I ask for the microseconds that I stored, You cannot expect to get that back exactly, because *the precision is not there* (and yes, the term here is precision not accuracy). Right now (late 2001) we have about seven digits of precision to the right of the decimal point in a timestamp. As we get further away from the 2000-01-01 origin, precision will drop; it'll be six digits or less by 2010. The further you go from 2000 in either direction, the worse the precision. This is an inherent property of float arithmetic and can't be papered over with display hacks, at least not without losing more than you gain. > Is there a better place to 'force' the accuracy of the fractional > second part that would be less prone to introduce other problems? You cannot force accuracy that isn't there. regards, tom lane
В списке pgsql-patches по дате отправления: