On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote: > >> After all, you've bitten the bullet now and changed the behavior. This > >> means that the semantics of some extant applications will change. So... in > >> for a penny, in for a pound? > > > The docs now say: > > > Field values can have fractional parts; for example, <literal>'1.5 > > weeks'</literal> or <literal>'01:02:03.45'</literal>. The fractional > > --> parts are used to compute appropriate values for the next lower-order > > internal fields (months, days, seconds). > > > meaning fractional years flows to the next lower internal unit, months, > > and no further. Fractional months would flow to days. The idea of not > > flowing past the next lower-order internal field is that the > > approximations between units are not precise enough to flow accurately. > > Um, what's the argument for down-converting AT ALL? The problem is > precisely that any such conversion is mostly fictional.
True. > > With my patch, the output is now: > > > SELECT INTERVAL '3 years 10.241604 months'; > > interval > > ------------------------ > > 3 years 10 mons 7 days > > > It used to flow to seconds. > > Yeah, that's better than before, but I don't see any principled argument > for it not to be "3 years 10 months", full stop. Well, the case was: SELECT INTERVAL '0.1 months'; interval ---------- 3 days SELECT INTERVAL '0.1 months' + interval '0.9 months'; ?column? ---------- 30 days If you always truncate, you basically lose the ability to specify fractional internal units, which I think is useful. I would say if you use fractional units of one of the internal units, you are basically knowing you are asking for an approximation --- that is not true of '3.5 years', for example. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.