Re: jsonpath versus NaN - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: jsonpath versus NaN
Date
Msg-id CAPpHfdsWeHKO_xhMwatLrJ=ZPBWDu40Qw7oEL1otmpEEY0G7OQ@mail.gmail.com
Whole thread Raw
In response to Re: jsonpath versus NaN  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: jsonpath versus NaN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov <aekorotkov@gmail.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



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: output columns of \dAo and \dAp
Next
From: Tom Lane
Date:
Subject: Re: jsonpath versus NaN