Re: jsonpath versus NaN

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: jsonpath versus NaN
Date: 2020-07-07 22:12:38
Message-ID: CAPpHfdsWeHKO_xhMwatLrJ=ZPBWDu40Qw7oEL1otmpEEY0G7OQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> The patchset is attached, sorry for the delay.
>
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to double precision type.
> If it doesn't fit, the current error message just says the following.
>
> ERROR: jsonpath item method .double() can only be applied to a numeric value
>
> But that's confusing, because .double() method is naturally applied to
> a numeric value. Patch makes this message explicitly report that
> numeric value is out of range for double type. This patch also adds
> test exercising this error. When string can't be converted to double
> precision, I think it's better to explicitly say that we expected
> valid string representation of double precision type.
>
> Second patch forbids to convert NaN using .double() method. As I get,
> NaN can't be result of any jsonpath computations assuming there is no
> NaN input. So, I just put an assert to convertJsonbScalar() ensuring
> there is no NaN in JsonbValue.

I'm going to push 0002 if there is no objection.

Regarding 0001, I think my new error messages need review.

------
Regards,
Alexander Korotkov

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-07 22:16:42 Re: jsonpath versus NaN
Previous Message Alexander Korotkov 2020-07-07 22:09:50 Re: output columns of \dAo and \dAp