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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: output columns of \dAo and \dAp
Следующее
От: Tom Lane
Дата:
Сообщение: Re: jsonpath versus NaN