From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
cc: Oleg Bartunov <obartunov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath versus NaN
In-reply-to: 
 <CAPpHfdvU4KNrbusUXr_hwv8Jd_GkJx0mzSY0TTAGPsexPxSn+Q@mail.gmail.com>
References: <203949.1591879542@sss.pgh.pa.us>
 <CAPpHfdtLr1MkBr0Sgzu+HO0fkEP3W11SmLtOoBwWox8MiQdpmA@mail.gmail.com>
 <355114.1591902003@sss.pgh.pa.us>
 <CAPpHfdtizzX++0DUVL0_CCJjp6Rd-NT9rmqe0PvL7-t62Eq0oA@mail.gmail.com>
 <1446772.1592407984@sss.pgh.pa.us>
 <CAF4Au4yPfxBO7HOryzoNpm_6y8c0gFHN=G_7wj6v5226HrKrKA@mail.gmail.com>
 <1552001.1592496464@sss.pgh.pa.us>
 <CAPpHfdvU4KNrbusUXr_hwv8Jd_GkJx0mzSY0TTAGPsexPxSn+Q@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <a.korotkov@postgrespro.ru>
	message dated "Thu, 18 Jun 2020 19:34:32 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1553460.1592498746.1@sss.pgh.pa.us>
Date: Thu, 18 Jun 2020 12:45:46 -0400
Message-ID: <1553461.1592498746@sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double.  However, standard references the standard behavior of
> CAST here, not behavior of your implementation of CAST.  So, if we
> extend the functionality of standard CAST in our implementation, that
> doesn't automatically mean we should extend the .double() jsonpath
> method in the same way.  Is it correct?

Right.  We could, if we chose, extend jsonpath to allow Inf/NaN, but
I don't believe there's an argument that the spec requires us to.

Also the larger point is that it doesn't make sense to extend jsonpath
that way when we haven't extended json(b) that way.  This code wart
wouldn't exist were it not for that inconsistency.  Also, I find it hard
to see why anyone would have a use for NaN in a jsonpath test when they
can't write NaN in the input json data, nor have it be correctly reflected
into output json data either.

Maybe there's a case for extending json(b) that way; it wouldn't be so
different from the work I'm doing nearby to extend type numeric for
infinities.  But we'd have to have a conversation about whether
interoperability with other JSON implementations is worth sacrificing
to improve consistency with our float and numeric datatypes.  In the
meantime, though, we aren't allowing Inf/NaN in json(b) so I don't think
jsonpath should accept them either.

			regards, tom lane