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
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 |