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 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
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.
No other comments.
regards, tom lane
