Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-02-19T23:40:59Z
Lists: pgsql-bugs
Attachments
- fix-E-notation-in-datetime-fields.patch (text/x-diff) patch
PG Bug reporting form <noreply@postgresql.org> writes: > I've encountered a pair of relatively new anomalies when using ISO-8601 > intervals. Thanks for the report! All of these seem to trace to the fact that ParseISO8601Number isn't considering the possibility that the input string ends with "eNN". This allows the reported "fraction" output to have values greater than 1, which breaks some calling code as you show, and it also fails to apply that scale factor to the integer part of the output, which accounts for some of the other cases. On the whole I think the right fix is to go back to using strtod() to parse the whole input string, as we did before e39f99046. This results in some inaccuracy if there's more than 15 digits in the input, but I don't care enough about that scenario to work harder. There are a couple of other places where datetime.c is using strtod() to parse what it expects to be a fractional value. I'm inclined to just barf if the result is out of range. Maybe we shouldn't back-patch that aspect into v15, not sure. Anyway I propose the attached. regards, tom lane
Commits
-
Fix parsing of ISO-8601 interval fields with exponential notation.
- f0d0394e84ce 16.0 landed
- ded5ede2779f 15.3 landed