Re: jsonpath versus NaN

Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> On Thu, Jun 11, 2020 at 3:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It is entirely clear from the code, the documentation,
>> and the relevant RFCs that JSONB does not allow NaNs as numeric
>> values.

> The JSONB itself doesn't store number NaNs. It stores the string "NaN".

Yeah, but you have a numeric NaN within the JsonbValue tree between
executeItemOptUnwrapTarget and convertJsonbScalar. Who's to say that
that illegal-per-the-data-type structure won't escape to somewhere else?
Or perhaps more likely, that we'll need additional warts in other random
places in the JSON code to keep from spitting up on the transiently
invalid structure.

> I found the relevant part of the standard. Unfortunately, I can't
> post the full standard here due to its license, but I think I can cite
> the relevant part.

I don't think this is very relevant. The SQL standard has not got the
concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers),
therefore their definition is only envisioning that a string representing
a normal finite number should be castable to DOUBLE PRECISION. Thus,
both of the relevant standards think that "numbers" are just finite
numbers.

So when neither JSON nor SQL consider that "NaN" is an allowed sort
of number, why are you doing violence to the code to allow it in a
jsonpath? And if you insist on doing such violence, why didn't you
do some more and kluge it to the point where "Inf" would work too?
(It would require slightly less klugery in the wake of the infinities-
in-numeric patch that I'm going to post soon ... but that doesn't make
it a good idea.)

regards, tom lane