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.
rfc and sql json forbid Nan and Inf ( Technical Report is freely available,
“A sequence comprising an integer part, optionally followed by a fractional part and/or an exponent part (non-numeric values, such as infinity and NaN are not permitted)”
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.
The problem is that we tried to find a trade-off between standard and postgres
implementation, for example, in postgres CAST allows NaN and Inf, and SQL Standard