From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <obartunov@postgrespro.ru>
cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath versus NaN
In-reply-to: 
 <CAF4Au4yPfxBO7HOryzoNpm_6y8c0gFHN=G_7wj6v5226HrKrKA@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>
Comments: In-reply-to Oleg Bartunov <obartunov@postgrespro.ru>
	message dated "Thu, 18 Jun 2020 18:51:04 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1552000.1592496464.1@sss.pgh.pa.us>
Date: Thu, 18 Jun 2020 12:07:44 -0400
Message-ID: <1552001.1592496464@sss.pgh.pa.us>
Precedence: bulk

Oleg Bartunov <obartunov@postgrespro.ru> writes:
> 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.

As I said, I think this is a fundamental misreading of the standard.
The way I read it is that it requires the set of values that are legal
according to the standard to be processed the same way as CAST would.

While we certainly *could* choose to extend jsonpath, and/or jsonb
itself, to allow NaN/Inf, I do not think that it's sane to argue that
the standard requires us to do that; the wording in the opposite
direction is pretty clear.  Also, I do not find it convincing to
extend jsonpath that way when we haven't extended jsonb.  Quite aside
from the ensuing code warts, what in the world is the use-case?

			regards, tom lane