Horton

Re: jsonpath versus NaN

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Oleg Bartunov <obartunov@postgrespro.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Korotkov <a.korotkov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-18T16:24:31Z
Lists: pgsql-hackers 
On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov <obartunov@postgrespro.ru> wrote:
> 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.

It seems like the right thing is to implement the standard, not to
implement whatever PostgreSQL happens to do in other cases. I can't
help feeling like re-using the numeric data type for other things has
led to this confusion. I think that fails in other cases, too: like
what if you have a super-long integer that can't be represented as a
numeric? I bet jsonb will fail, or maybe it will convert it to a
string, but I don't see how it can do anything else.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Forbid numeric NaN in jsonpath

  2. Improve error reporting for jsonpath .double() method

  3. Partial implementation of SQL/JSON path language