From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | John W Higgins <wishdev(at)gmail(dot)com> |
Cc: | pgsql-hackers list <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Have I found an interval arithmetic bug? |
Date: | 2021-07-28 07:42:31 |
Message-ID: | CAEZATCWaK0qdTiqxS=fM03VaKcfbYmSOV_JzqYDrVn2nSaMnFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, 28 Jul 2021 at 00:08, John W Higgins <wishdev(at)gmail(dot)com> wrote:
>
> It's nice to envision all forms of fancy calculations. But the fact is that
>
> '1.5 month'::interval * 2 != '3 month"::interval
>
That's not exactly true. Even without the patch:
SELECT '1.5 month'::interval * 2 AS product,
'3 month'::interval AS expected,
justify_interval('1.5 month'::interval * 2) AS justified_product,
'1.5 month'::interval * 2 = '3 month'::interval AS equal;
product | expected | justified_product | equal
----------------+----------+-------------------+-------
2 mons 30 days | 3 mons | 3 mons | t
(1 row)
So it's equal even without calling justify_interval() on the result.
FWIW, I remain of the opinion that the interval literal code should
just spill down to lower units in all cases, just like the
multiplication and division code, so that the results are consistent
(barring floating point rounding errors) and explainable.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Atul Kumar | 2021-07-28 09:32:02 | pganalyze setup |
Previous Message | M Tarkeshwar Rao | 2021-07-28 06:51:22 | How postgres is refreshing TLS certificates |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-07-28 09:01:47 | Re: proposal: enhancing plpgsql debug API - returns text value of variable content |
Previous Message | Richard Guo | 2021-07-28 07:42:15 | Problem about postponing gathering partial paths for topmost scan/join rel |