Re: jsonpath versus NaN

On Wed, Jun 17, 2020 at 6:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > On Thu, Jun 11, 2020 at 10:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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,
https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_19075-6_2017.zip
)

Page 10 JSON terminology.
“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
requires .double should works as CAST.

SELECT 'nan'::real, 'inf'::real;
float4 | float4
--------+----------
NaN | Infinity
(1 row)

>
> regards, tom lane
>
>
>

--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company