From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
Date: Mon, 20 Feb 2023 13:00:00 +0300
Message-ID: <18486f0e-cdfa-49b3-c863-bb83bdd8a097@gmail.com> (raw)
In-Reply-To: <3449142.1676850059@sss.pgh.pa.us>
References: <17795-748d6db3ed95d313@postgresql.org>
<3449142.1676850059@sss.pgh.pa.us>
20.02.2023 02:40, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> I've encountered a pair of relatively new anomalies when using ISO-8601
>> intervals.
>>
>>
>> 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.
This approach seems less fragile to me. All my examples shown before
work as expected now.
Thanks!
>> 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.
Looking at the callers of the ParseFraction() and DecodeNumberField()
I see only DecodeDate(), DecodeDateTime(), DecodeTimeOnly(),
and DecodeInterval(). All these functions pass to ParseFraction()
and DecodeNumberField() not full "fractional" strings, but fields, that
were extracted before. For example, with "SELECT time 'J0.5e1';"
there are three fields "j", "0.5", "e1" passed to DecodeTimeOnly(),
or with "SELECT interval '1.5e1';" I see fields "1.5" and "e1".
(Maybe I miss something.)
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.
Best regards,
Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: exclusion@gmail.com, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()
In-Reply-To: <18486f0e-cdfa-49b3-c863-bb83bdd8a097@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox