Re: 8.3 vs HEAD difference in Interval output?
От | Ron Mayer |
---|---|
Тема | Re: 8.3 vs HEAD difference in Interval output? |
Дата | |
Msg-id | 48EEE53B.6030505@cheapcomplexdevices.com обсуждение исходный текст |
Ответ на | Re: 8.3 vs HEAD difference in Interval output? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Ron Mayer <rm_pg@cheapcomplexdevices.com> writes: >> Tom Lane wrote: >>> We could try to do the same in the float case, but I'm a bit worried >>> about finding ourselves showing "1234567.799999" ... >> If I understand the code right [I didn't...] > > The problem is ... seconds field that includes hours, > minutes, seconds, and fractional seconds...Here's an example... > regression=# select '1234567890 hours 0.123 sec'::interval; > ... 1234567890:00:00.123047 Hmm. That's also an existence proof that we're not too concerned about showing 6 imprecise digits anyway (at least for some 8.3 DateStyles). Doesn't seem like it'd hurt too much if we show them for all the IntervalStyles. > Since there's a (somewhat arbitrary) limitation of the hours to 2^31, > this is close to the worst possible case. (Hm, maybe someone actually > did the math and decided that 2 fractional digits ... Or I guess we could truncate to 2 digits only in the float case; or truncate to 2 digits only if we're using the float case and have large values. But that extra complexity doesn't seem worth it to me - especially since it seems to only affect people who do two non-default things (pick a date/interval style that used to truncate to 2, and --disable-integer-datetimes). I put a patch up at http://0ape.com/postgres_interval_patches that does what I think seems getting reasonable. For better or worse, it depends on the other two interval patches I was working on, but I could make a version that doesn't depend on those as well if people prefer that.
В списке pgsql-hackers по дате отправления: