From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <obartunov@postgrespro.ru>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath versus NaN
Date: Thu, 18 Jun 2020 12:07:44 -0400
Message-ID: <1552001.1592496464@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, obartunov@postgrespro.ru, a.korotkov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: jsonpath versus NaN
In-Reply-To: <1552001.1592496464@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox