> On 12-Apr-2021, at 17:00, Bruce Momjian <bruce@momjian.us> wrote:
>
> 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.
I’d argue that the fact that this:
('0.3 months'::interval) + ('0.7 months'::interval)
Is reported as '30 days' and not '1 month' is yet another bug—precisely because of what I said in my previous email
(sorrythat I forked the thread) where I referred to the fact that, in the right test, adding 1 month gets a different
answerthan adding 30 days. Yet another convincing reason to get rid of this flow down business altogether.
If some application wants to model flow-down, then it can do so with trivial programming and full control over its own
definitionof the rules.