From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Oleg Bartunov <obartunov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath versus NaN
Date: Thu, 18 Jun 2020 12:45:46 -0400
Message-ID: <1553461.1592498746@sss.pgh.pa.us> (raw)
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>
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
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, a.korotkov@postgrespro.ru, obartunov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: jsonpath versus NaN
In-Reply-To: <1553461.1592498746@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