Re: jsonpath versus NaN

On Thu, Jul 9, 2020 at 1:20 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > 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.
>
> I see your point here, but the English of the replacement error messages
> could be improved. I suggest respectively
>
> numeric argument of jsonpath item method .%s() is out of range for type double precision
>
> string argument of jsonpath item method .%s() is not a valid representation of a double precision number

Good, thank you for corrections!

> As for 0002, I'd rather see the convertJsonbScalar() code changed back
> to the way it was, ie just
>
> case jbvNumeric:
> numlen = VARSIZE_ANY(scalarVal->val.numeric);
> padlen = padBufferToInt(buffer);
> ...
>
> There is no argument for having an its-not-NaN assertion here when
> there aren't similar assertions throughout the jsonb code.
>
> Also, it seems like it'd be smart to reject isinf() and isnan() results
> from float8in_internal_opt_error in both executeItemOptUnwrapTarget code
> paths, ie numeric source as well as string source. Yeah, we don't expect
> to see those cases in a jbvNumeric (so I wouldn't change the error message
> text), but it's cheap insurance.

OK, corrected as you proposed.

> No other comments.

Revised patches are attached.

I understand both patches as fixes and propose to backpatch them to 12
if no objections.

------
Regards,
Alexander Korotkov