| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Oleg Bartunov <obartunov(at)postgrespro(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: jsonpath versus NaN |
| Date: | 2020-06-18 16:24:31 |
| Message-ID: | CA+TgmobNwqNf2=4+sXy5_Y1FpWcxYf7ybkt-dk1dQqSTkB_qGg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov <obartunov(at)postgrespro(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-06-18 16:29:40 | Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks) |
| Previous Message | Robert Haas | 2020-06-18 16:21:51 | Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks) |