Re: jsonpath versus NaN

Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Thu, Jun 11, 2020 at 10:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Yes, I see.  No standard insists we should support NaN.  However,
> standard claims .double() should behave the same as CAST to double.
> So, I think if CAST supports NaN, but .double() doesn't, it's still a
> violation.

No, I think you are completely misunderstanding the standard.  They
are saying that strings that look like legal numbers according to SQL
should be castable into numbers.  But NaN and Inf are not legal
numbers according to SQL, so there is nothing in that text that
justifies accepting "NaN".  Nor does the JSON standard provide any
support for that position.  So I think it is fine to leave NaN/Inf
out of the world of what you can write in jsonpath.

I'd be more willing to let the code do this if it didn't require such
a horrid, dangerous kluge to do so.  But it does, and I don't see any
easy way around that, so I think we should just take out the kluge.
And do so sooner not later, before some misguided user starts to
depend on it.

			regards, tom lane