Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
Date: 2023-02-20 21:59:24
Message-ID: 3801960.1676930364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Lakhin <exclusion(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2023-02-20 22:49:25 Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash
Previous Message Stephen Frost 2023-02-20 20:58:36 Re: Query run in 27s with 15.2 vs 37ms with 14.6