From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath versus NaN
In-reply-to: 
 <CAPpHfdtqJtiSXkP7tOXez18NxhLUH_-75bL8=Oce4Ki+bv7V6Q@mail.gmail.com>
References: <203949.1591879542@sss.pgh.pa.us>
 <CAPpHfdtLr1MkBr0Sgzu+HO0fkEP3W11SmLtOoBwWox8MiQdpmA@mail.gmail.com>
 <355114.1591902003@sss.pgh.pa.us>
 <CAPpHfdtizzX++0DUVL0_CCJjp6Rd-NT9rmqe0PvL7-t62Eq0oA@mail.gmail.com>
 <1446772.1592407984@sss.pgh.pa.us>
 <CAF4Au4yPfxBO7HOryzoNpm_6y8c0gFHN=G_7wj6v5226HrKrKA@mail.gmail.com>
 <1552001.1592496464@sss.pgh.pa.us>
 <CAPpHfdvU4KNrbusUXr_hwv8Jd_GkJx0mzSY0TTAGPsexPxSn+Q@mail.gmail.com>
 <1553461.1592498746@sss.pgh.pa.us>
 <CAPpHfdtP6Y2dH6_WG-1xEj+GHJ6mdbWA3O+y5tFEBunQdA_SPw@mail.gmail.com>
 <CAPpHfdtqJtiSXkP7tOXez18NxhLUH_-75bL8=Oce4Ki+bv7V6Q@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
	message dated "Mon, 06 Jul 2020 15:19:21 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1736147.1594246857.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 08 Jul 2020 18:20:57 -0400
Message-ID: <1736148.1594246857@sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <aekorotkov@gmail.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 v=
alue

> 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 do=
uble precision

string argument of jsonpath item method .%s() is not a valid representatio=
n of a double precision number

As for 0002, I'd rather see the convertJsonbScalar() code changed back
to the way it was, ie just

 		case jbvNumeric:
 			numlen =3D VARSIZE_ANY(scalarVal->val.numeric);
 			padlen =3D 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.

No other comments.

			regards, tom lane