From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Bryn Llewellyn <bryn(at)yugabyte(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, John W Higgins <wishdev(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Have I found an interval arithmetic bug? |
Date: | 2021-04-05 18:37:54 |
Message-ID: | 20210405183754.GC12179@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote:
> On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
> > > > « …field values can have fractional parts; for example '1.5 week' or '01:02:03.45'. Such input is converted to the appropriate number of months, days, and seconds for storage. When this would result in a fractional number of months or days, the fraction is added to the lower-order fields using the conversion factors 1 month = 30 days and 1 day = 24 hours. For example, '1.5 month' becomes 1 month and 15 days. Only seconds will ever be shown as fractional on output. »
> >
> > I see that. What is not clear here is how far we flow down. I was
> > looking at adding documentation or regression tests for that, but was
> > unsure. I adjusted the docs slightly in the attached patch.
>
> I should have adjusted the quote to include context:
>
> | In the verbose input format, and in SOME FIELDS of the more compact input formats, field values can have fractional parts[...]
>
> I don't know what "some fields" means - more clarity here would help indicate
> the intended behavior.
I assume it is comparing the verbose format to the ISO 8601 time
intervals format, which I have not looked at. Interesting I see this as
a C comment at the top of DecodeISO8601Interval();
* A couple exceptions from the spec:
* - a week field ('W') may coexist with other units
--> * - allows decimals in fields other than the least significant unit.
I don't actually see anything in our code that doesn't support factional
values, so maybe the docs are wrong and need to be fixed.
Actually, according to our regression tests, this fails:
SELECT '5.5 seconds 3 milliseconds'::interval;
ERROR: invalid input syntax for type interval: "5.5 seconds 3 milliseconds"
but that is the verbose format, I think.
> > The interaction of months/days/seconds is so imprecise that passing it
> > futher down doesn't make much sense, and suggests a precision that
> > doesn't exist, but if people prefer that we can do it.
>
> I agree on its face that "months" is imprecise (30, 31, 27, 28 days),
> especially fractional months, and same for "years" (leap years), and hours per
> day (DST), but even minutes ("leap seconds"). But the documentation seems to
> be clear about the behavior:
>
> | .. using the conversion factors 1 month = 30 days and 1 day = 24 hours
>
> I think the most obvious/consistent change is for years and greater to "cascade
> down" to seconds, and not just months.
Wow, well, that is _an_ option. Would people like that? It is certainly
easier to explain.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-04-05 18:41:31 | Re: Is replacing transactions with CTE a good idea? |
Previous Message | Dave Cramer | 2021-04-05 18:32:36 | Re: Is replacing transactions with CTE a good idea? |
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2021-04-05 19:23:05 | Re: Stronger safeguard for archive recovery not to miss data |
Previous Message | Stephen Frost | 2021-04-05 18:33:41 | Re: [PATCH] New default role allowing to change per-role/database settings |