On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@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
applicationswill 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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
