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: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-02-20T21:59:24Z
Lists: pgsql-bugs
Alexander Lakhin <exclusion@gmail.com> writes: > 20.02.2023 02:40, Tom Lane wrote: >> 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. > I could not find a way to pass the e-notation there. True, I was thinking of this as future-proofing not as closing any live loophole. > Also, the comment added makes me wonder, whether ".1e-10" > (e.g., in "1.1e-10") can be considered bogus too. I would say so > (if we are going to just add a fraction produced by ParseFraction() > to some integer part later, we still get the wrong result > (for the scientific notation)), and if we want to have > a consistent syntax, maybe it's worth to check an input string for 'e'/'E', > but if not, then maybe leave it alone. I would prefer the latter for now. Fair enough. I pushed the ParseISO8601Number fix without touching the other two places. regards, tom lane
Commits
-
Fix parsing of ISO-8601 interval fields with exponential notation.
- f0d0394e84ce 16.0 landed
- ded5ede2779f 15.3 landed