Re: jsonpath versus NaN
От | Alexander Korotkov |
---|---|
Тема | Re: jsonpath versus NaN |
Дата | |
Msg-id | CAPpHfdsWeHKO_xhMwatLrJ=ZPBWDu40Qw7oEL1otmpEEY0G7OQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: jsonpath versus NaN (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: jsonpath versus NaN
|
Список | 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 по дате отправления: