Re: jsonpath versus NaN
Alexander Korotkov <a.korotkov@postgrespro.ru>
From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Oleg Bartunov <obartunov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-18T16:34:32Z
Lists: pgsql-hackers
Tom, On Thu, Jun 18, 2020 at 7:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. 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? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Forbid numeric NaN in jsonpath
- f4ae676e3178 12.4 landed
- 89a0b1a7ca0a 13.0 landed
- df646509f371 14.0 landed
-
Improve error reporting for jsonpath .double() method
- 3ec5f6b53dfb 12.4 landed
- b9a04a9bc665 13.0 landed
- 065718116746 14.0 landed
-
Partial implementation of SQL/JSON path language
- 72b6460336e8 12.0 cited